rynowak

LOL What?

Allows you to write methods that contain mixed HTML and C# in Razor Views (.cshtml) / Razor Components (.razor) files.

This is a primitive for composing Razor code that is very low overhead / low concept. Your code calls your code.

In Views (not components): Can be async, can use tag helpers. In Components (not views): Usage and semantics still need figuring out, but we want to build something like this.

Sample

rynowak

Bind cases

Option 0: (current state)

<input type="text" bind="@person.Name" />
<input type="text" bind-value="@person.Name" />
<input type="text" bind-value-oninput="@person.Name" />

rynowak

Summary

ASP.NET Core startup code follows regular patterns that are suitable for code analysis and enhancements to the coding experience through analyzers, code fixes, and smarter scaffolding.

What things that analyzers could provide would be most valuable?

Things that analyzers can easily understand:

• What services are registered? (ex: AddMvc() includes AddRouting())
• What options are set? (ex: AddMvcOptions(options => options.EnableEndpointRouting = false)
• What middleware do you have? (ex: UseHealthChecks())

rynowak

API Template small single exe Roadmap

This document is a proposal for leveraging the learnings from the small-single-exe working group in ASP.NET Core in an immediately actionable way. All of these changes are aimed at improving one or more of the metrics that we're tracking for the single-effort without bad scenario takebacks.

There's still some design and scenario work to do here for ASP.NET Core - these aren't specs - the goal of this document to capture how we can apply learnings from this effort and accounting for what we stand to gain.

Executive Summary

We've completed the prototyping exercise, our primary results:

rynowak

On Linkability and Size

Optimizing a .NET application for size requires us to develop new muscles, new tools, new designs, and new criteria for decision making. We typically provide customer value though building rich and powerful APIs. Optimizing for size asks something new of us, wanting granular APIs, uncoupled features, and statically-analyzable patterns.

Of the top ten non-Microsoft .NET library packages on nuget.org - 6/10 of these libraries serve the primary purpose of doing dynamic code invocation (IoC).

• Newtonsoft.Json (Serializer)
• Castle.Core (Reflection/IL utilities)
• Moq (Mocking/Proxies/IL Generation)
• Automapper (Object-Mapping)

rynowak

Routing in the small

ASP.NET Core 3.0 adds new some infrastructure that makes programming in the small (few methods/classes) more convenient.

These scenarios feel more immediate when you can use local functions, and it really benefits from being able to place attributes on them. In particular, placing attributes on parameters is one of the only ways we can provide expressiveness about where the arguments should come from (injecting a DbContext from services in my example).

Using lambdas is an option as well, but for many of these cases the user wants to explicitly specify the types, so it's a small jump in complexity to a local function.

I'm not sure which of these we'd pick stylistically for our samples/blogs - but I'm sure some users will want to do this and it's come up during our internal discussions. I wanted to pass on the feedback about this feature, we have a concrete use case for it.

rynowak

Radius workshop

Written by the shores of Lake Tahoe.....

This document is the overall framing of a Radius workshop that we would produce. The goals of this document are to:

• Align the team on the purpose of the workshop and format.
• Align the team on an overall outline so we can assign owners and start work.

Goals of the workshop

rynowak

Public Release +1 Planning

This document provides framing for public release +1 - meaning: what are the next set of goals and investments for Radius post-public-release.

Since we moved our announce date back we'll have time to do more before the actual initial release. Additionally we need to build a public roadmap and publish it as part of the project. This document acts as an input to support both those goals.

Updates to goals

Our goals for public release as started original were:

rynowak

Application Model Innovation

Application Model: A document or API that describes a cloud application's configuration and requirements in a way that can be deployed and run.

Industry Landscape

Application models, delivery, and deployment tooling is a target-rich environment with many projects. Developers don't like application deployment and aren't good at it, but making developers more productive is always an important problem to solve. Complexifying this, there are many different models of how organizations work, whether they have separate disciplines, and which people have different responsibilities.

The result is that there's a huge diversity of a projects, no standard terminology, and no one project gets critical mass.

rynowak

Test Plan for Recipes

This document is the starting point for a Recipes test plan. The goal of this document is that we can have a brainstorm together and fill in the plan with input from the whole team. @rynowak will hold the pen for writing the final document, and @kachalwa is the approver. The work that's detailed here will feed into the individual items being driven by feature owners (functional tests are part of the definition of done).

Our goal for this discussion is to introduce the idea of a test plan, collect, and refine input.

We're doing this now because we're executing on Terraform recipes in a highly parallel well. Getting a shared understanding of the test strategy will help individuals build the right tests by doing some big-picture-thinking upfront.

We've also had a lot of churn in our design practices for tests and recently done some thinking about concepts like: