Flexible starting components for modules.

[markdav-is]

When we add a module to a page, the index.razor is the default starting module. This makes perfect sense. In the case of lots of little one-page modules, when combined into a multi-module project, you end up with lots of components called index.razor separated by folders and namespaces. In this case it would be handy to have less namespaces and more differently named razor files.

example current:

• module
  • SomeAdminModule
    • Index.razor
  • AnotherAdminModule
    • Index.razor

example proposed:

• module
  • SomeAdmin.razor
  • AnotherAdmin.Razor

This configuration has some usability advantages. When most of your components are named index.razor, switching between editors can get confusing.

Options for implementation:

• Option one: startup component selector
• • To facilitate selecting one of these alternate components as the starting component for the module will require reworking code in the module loading, adjusting the PageModule schema to add a StartComponent column, and adjusting the Add Module UI to allow the selection of the starting component from a list of components that inherit from modulebase.
• Option two: decorator interface
• • An alternative solution would be to decorate components that impliment modulebase with an interface like IModuleIndex and then list each of these as modules. This might be a better short-term solution, but I think eventually, we'll end up with thousands of "modules" when we really want a fewer modules with numerous entry-points each.

[sbwalker]

I think the simplest option and the one which may preserve the existing performance characteristics is to add an optional property to the ModuleDefinition model named DefaultComponent - which would allow a developer to specify the value in their IModule interface. This is the purpose of the IModule interface - to provide metadata which governs the behavior of the module.

[sbwalker]

The other option of course is to support both approaches - it makes the core implementation a bit more complicated but these solutions could complement each other

[PizzaConsole]

Both sounds intriguing. Honestly I feel like the PR i did is just default behavior that the framework should already have. Like I said the Actions behavior already works when inside the module. I would be in favour of doing both.

Also it would be easy during copy/paste for a developer to mistakenly include the Action property definition in multiple components within the same module which would lead to undesired behavior.

Isn't this technically already a con of how the actions currently work?

[PizzaConsole]

@markdav-is This feature is now available via the latest PR merge

[sbwalker]

I am also introducing the DefaultAction option described above - so you will have a couple of solutions to your issue.

[markdav-is]

Wow. Thanks! I really appreciate it.

[PizzaConsole]

I am very curious, how you are using the modules. What would be the reason for so many single page modules?

[markdav-is]

config settings. pages and pages of config settings.