Add support for nested menus

[mpourismaiel]

What this PR does / why we need it:
Add support for nested main menus in nav fragment

Which issue this PR fixes:
fixes #683

Release note:

- nav: Add support for nested menus by adding dropdowns

[stp-ip]

We should at least have an example within our docs and maybe even a test case.

[stp-ip]

What do you think about adding a link back to the nesting docs from Hugo at least as a reference or footnote.
https://gohugo.io/content-management/menus/#nesting

What's your stance on a test for this?

[mpourismaiel]

In order to add a test we have to create a new website or add nesting menus to our demo. Is there a menu we want in the demo that can be nested?

[stp-ip]

One idea would be an additional nav for dev with a few nested pages for colors for example. That would test multiple navy as well as nesting. Thoughts?

[mpourismaiel]

Problem is menus are global, adding a nested menu would add it everywhere. Is it okay to add a menu to every page to link to colors page?

[stp-ip]

Can't we do something in config-dev.toml such as:

  [[menu.dev]]
    url = "/dev"
    name = "Dev"
    weight = 10
    identifier = "dev"

  [[menu.dev]]
    url = "/dev/colors/<fragment>"
    name = "Color <fragment>"
    weight = 10

  [[menu.dev]]
    url = "/dev/colors/<fragment>"
    name = "Color <fragment>"
    weight = 20

Not sure why this needs to be global?

[mpourismaiel]

Only menu.main supports dropdown in nav. Do we allow for custom menus in nav fragment?

[stp-ip]

Ahh good point. Missed that nested is done via menu.main.

Within the config-dev.toml we could add the dev section within the main menu I assume, which then has a nested menu. What do you think? Would be helpful I guess.

Currently we don't allow for custom menus in nav yet, but with multiple navs on the same page, we probably should or?

[mpourismaiel]

As you mentioned in the past, menus offer unique features from Hugo that we can't replicate. As we don't use most of them for now, we can allow a custom menu and disabling the main menu in nav fragment which would be helpful in some situations. But nav fragment already has too many options and adding a new one might make the complexity too much. Not sure though.

I will add a dev menu to the navbar which would allow us to create tests for the dropdown. We can discuss the addition of custom menus in another issue if you agree.

[stp-ip]

Damn I love that you just let me reflect and reconsider adding another option. Good points. Let's discuss this in another issue.

[mpourismaiel]

Haha. Also I think testing shouldn't be done here. We should however write tests for our bootstrap and jquery helpers. Should I create a tracking issue?

[stp-ip]

What's your reasoning behind not adding tests? As this is a Hugo function and bootstrap, which should work or be tested on their side?

[mpourismaiel]

The nested menu is a Hugo feature and works from their side, our testing would be on top of theirs which seems redundant. But dropdown, although taken from bootstrap and using bootstrap styles, is implemented by us and therefore should be tested. And since there are other functionalities like it implemented, I think writing tests for all of them in a separate PR is cleaner.

[stp-ip]

Sounds good.

[mpourismaiel]

Is there anything else we can do on this PR?

[stp-ip]

Thought we still wanted to add the nested menu into config-dev.toml or did we want this to happen in a separate PR?

[stp-ip]

edit: damn wrong tab

[mpourismaiel]

I thought I pushed the commits. Sorry :D

[mpourismaiel]

Also created tests within #791

[stp-ip]

Not sure I agree with having them in the normal config.toml as well.
That one is more likely to be copied such as to our demo page, which doesn't use the /dev/ pages.

Any reason why you added them here as well?

[mpourismaiel]

We aren't using config.toml in Netlify and it's not used in package.json as well. I thought since it's not in any of those files it's not used at all so updated it just to keep it in line with config-dev.toml. I removed the menus from it now.

[stp-ip]

Tests can be approved separately then as you mentioned they are in the jq PR.

Let's clear up the above comment on config.toml inclusion and then get this merged.