Aspnetcore: Code Extraction from Razor files to backing C#

Created on 26 May 2020  路  3Comments  路  Source: dotnet/aspnetcore

This is an elaboration on the first item in #21901 for discussion of design and implementation of this language server feature.

Done area-razor.tooling enhancement feature-razor.languageserver

Most helpful comment

Feature behavior overview

  • Provides code actions on @code blocks as well as top-level members within said blocks that enable extraction of the relevant content into codebehind.
  • Doesn't support code blocks with embedded markup.
  • On extraction, removes code blocks that will end up being empty.
  • Only checks if <name>.razor has an existing adjacent <name>.razor.cs file to insert the extracted code into (rather than searching for all partial classes in the namespace) to avoid ambiguity and skip extra work.
  • Inserts the extracted code below any existing body in the codebehind partial, creating the namespace and class if one or both do not exist.
  • Also extracts related documentation for toplevel members.

All 3 comments

Feature behavior overview

  • Provides code actions on @code blocks as well as top-level members within said blocks that enable extraction of the relevant content into codebehind.
  • Doesn't support code blocks with embedded markup.
  • On extraction, removes code blocks that will end up being empty.
  • Only checks if <name>.razor has an existing adjacent <name>.razor.cs file to insert the extracted code into (rather than searching for all partial classes in the namespace) to avoid ambiguity and skip extra work.
  • Inserts the extracted code below any existing body in the codebehind partial, creating the namespace and class if one or both do not exist.
  • Also extracts related documentation for toplevel members.

Some thoughts

  • Endpoints that provide CodeActions through OmniSharp will generally share a lot of computed data, so the detection mechanism for sets of related code actions can be condensed to reduce calls to parse the document, etc.
  • Services can be registered to analyze specific code action cases when a basic set of requirements are determined to be met by the overarching code action endpoint. For example, the refactoring endpoint will rely on a CodeExtractionService to check whether this particular case is valid for code extraction as well as what workspace edits to make after.
  • There are certain common tasks I expect I'll be repeating, such as locating a parsing documents. A caching system or a separate service are probably in order to aggregate all this information into a single place.
  • The refactoring endpoint will probably end up having some kind of struct with relevant data already parsed by the initial check (syntax tree, document snapshot, etc.) that can be passed alone with the CodeActionParams to the peripheral services.

One piece which will make everything feel more complete is on extraction have the resultant code be indented correctly.

Was this page helpful?
0 / 5 - 0 ratings