…omponent

Split out Views::MenuItem and Views::Menu

I do think the changes in #5163 are good but ideally the sorting should be done at the data layer, not in the DOM (Arbre). It has too though since the label, url, etc. have to rendered within the view context so its convenient to do there. I did this partial revert, because it would be easiest to use this within an extracted partial that the app host can customize to meet their needs. It is expected that a context has to be passed in for label, etc. since we have to render these blocks so no real way around that. The menu and menu item files haven't changed before #5163 for many years so I think the API is stable and solid for now.

I do think the changes in #5163 are good but ideally the sorting should be done at the data layer, not in the DOM (Arbre). It has too though since the label, url, etc. have to rendered within the view context so its convenient to do there. I did this partial revert, because it would be easiest to use this within an extracted partial that the app host can customize to meet their needs. It is expected that a context has to be passed in for label, etc. since we have to render these blocks so no real way around that. The menu and menu item files haven't changed before #5163 for many years so I think the API is stable and solid for now.

I do think the changes in #5163 are good but ideally the sorting should be done at the data layer, not in the DOM (Arbre). It has too though since the label, url, etc. have to rendered within the view context so its convenient to do there. I did this partial revert, because it would be easiest to use this within an extracted partial that the app host can customize to meet their needs. It is expected that a context has to be passed in for label, etc. since we have to render these blocks so no real way around that. The menu and menu item files haven't changed before #5163 for many years so I think the API is stable and solid for now.

I do think the changes in #5163 are good but ideally the sorting should be done at the data layer, not in the DOM (Arbre). It has too though since the label, url, etc. have to rendered within the view context so its convenient to do there. I did this partial revert, because it would be easiest to use this within an extracted partial that the app host can customize to meet their needs. It is expected that a context has to be passed in for label, etc. since we have to render these blocks so no real way around that. The menu and menu item files haven't changed before #5163 for many years so I think the API is stable and solid for now.

* Inline site footer styles with tailwind classes

Now that we've moved this to a partial, no need to keep the styles as a component class. We did that for others to be able to easily override using CSS but no point in that since the footer is really meant for the user to completely customize without any defaults applied.

* Extract sidebar to partials

This allows users to customize the sidebar further if needed since these are simple components.

The `attributes_table` method has been removed since it was a bad change. Sidebars can be used outside the show page context so by using `resource` internally that can lead to an unexpected error. This cleans up the API and matches what we have in the docs since we consistently show `attributes_table_for object, ...` usage.

This also removes the unused sidebar methods from resource controller. This same module is duplicated and available as view helpers which are public so this is unnecessary. It has no references, nor any documentation. This adds test coverage for the sidebar helper which was missing.

* Extract page header to partials

For the action items, this incorporates the changes from #7085 to avoid unintended flex gap on the default action items when there are none to render. Since the conditional was within the block that was too late. It has to be added as if block like any other action item.

* Extract site header to partial

* Extract logout link to partial, remove configs

We don't need the logout_link_method anymore since it's in a partial the host app is expected to update. Further the routes config we generate includes our Devise config which the host app can easily merge a sign_out_via override.

* Revert nested submenus from #5994

We've already removed SASS so this is a revert of the behavioral change. It's not recommend for main navigations to have more than a single nested menu level. Further since the menu only rendered horizontally when the change was introduced, we now render the menu vertically as a drawer style component for mobile support.

* Partial revert of #5163 for main menu extraction

I do think the changes in #5163 are good but ideally the sorting should be done at the data layer, not in the DOM (Arbre). It has too though since the label, url, etc. have to rendered within the view context so its convenient to do there. I did this partial revert, because it would be easiest to use this within an extracted partial that the app host can customize to meet their needs. It is expected that a context has to be passed in for label, etc. since we have to render these blocks so no real way around that. The menu and menu item files haven't changed before #5163 for many years so I think the API is stable and solid for now.

* Extract main menu to site header partial

* Remove unused index_scopes view factory

All that remains are the pages which will start to extract separately and then remove this view factory.

* Inline styles in flash messages partial

* Update button styles

* Add dark mode toggle

Defaults to system preference