[2.x] Refactor navigation internals to store navigation in the kernel

[emmadesilva]

No description provided.

[emmadesilva]

This breaks due to NavItem constructor forcing routes to strings which makes the links resolve too early. We can't evaluate dynamic links until individual page compile time.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (7e2d3d5) 99.95% compared to head (7b6b987) 99.95%.
Report is 297 commits behind head on 2.x-dev.

Additional details and impacted files

@@            Coverage Diff             @@
##             2.x-dev    #1538   +/-   ##
==========================================
  Coverage      99.95%   99.95%           
- Complexity      1746     1754    +8     
==========================================
  Files            181      181           
  Lines           4725     4738   +13     
==========================================
+ Hits            4723     4736   +13     
  Misses             2        2           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[emmadesilva]

Consider updating dropdown handling according to following proposed docs:

Dropdowns are represented by a NavItem with a children array containing more NavItem instances.

[emmadesilva]

Wondering if this API could be used in the config to initialize menus. It's kinda Filamenty. Since we don't cache configs (except for in the standalone which uses a caching hack) it should not be a problem. Worst case, that can be serialized in our configuration loader.

  'menus' => [
       NavigationMenu::create('main')
           ->withPageTypes('all', except: [DocumentationPage::class])
           ->withoutPages('404')
           ->withLabels([
               'home' => 'Start',
               'about' => 'About Us',
           ])
           ->withPriorities([
               'home' => 100,
               'about' => 200,
           ]),
       
       NavigationMenu::create('docs')
           ->withPageTypes(DocumentationPage::class)
           ->withLabels([
               'readme' => 'Readme',
               'installation' => 'Installation',
               'getting-started' => 'Getting Started',
           ])
           ->withPriorities([
               'readme' => 100,
               'installation' => 200,
               'getting-started' => 300,
           ])
           ->withoutPages([
               '404',
               'changelog'
           ]),
   ],

They can be accessed like this:

$main = NavigationMenu::get('main'); // Main menu
$docs = NavigationMenu::get('docs'); // Sidebar
$foo = NavigationMenu::get('foo'); // Throws with message stating menu must be specified in config

We could of course add the defaults to the base classes, so only overwrites would be needed.

NavigationMenu::main()
NavigationMenu::docs()
NavigationMenu::create() // For custom ones

And users could easily add their own navigation menus.

    NavigationMenu::create('footer')
        ->withRoutes(routeKeys: [
            'privacy-policy',
            'terms-of-service',
        ])
        ->withNavItems([
            NavItem::create(...['some data']),
            NavItem::create(...['some data']),
        ])
        ->withLinks([
            'External Link' => 'https://example.com',
        ])
    
        // Or shorthand
        ->with(routeKeys: [
            'privacy-policy',
            'terms-of-service',
        ], links: [
            'External Link' => 'https://example.com',
        ]),

We could also have subdirectory configuration on a per menu basis

    NavigationMenu::create('docs')
        ->useSubdirectoriesAs('dropdown')

[emmadesilva]

I think I need to hold of on this implementation for a bit. It doesn't support multiple navigation menus well.