Refactor to Glimmer components about ember-bootstrap

[SanderKnauff]

Got it. Moving to <BsNav> is not possible.

I wonder if it is needed anymore at all. It seems to be used to set active and disabled CSS classes on <li class="nav-item">.

I cannot find having active or disabled CSS class on <li class="nav-item"> for Bootstrap 4 or 5 in Bootstrap's documentation. I can only find it in Bootstrap 3. In Bootstrap 4 and 5 the active and disabled CSS classes are on the <a> element, which is rendered by <BsLinkTo> itself.

Unless I missed something the code seems to be a leftover from Bootstrap 3 support, which we missed to remove. Would be great if you could double check as well.

Assuming I haven't missed something, I would recommend doing 2 PRs:

1. Removing active and disabled CSS classes from <li class="nav-item"> and all code related to it.
2. Refactoring <BsNav::Item> to Glimmer component, which should be unblocked after we landed the cleanup in first step.

I prefer two PRs to highlight the markup change more prominently in changelog. I don't think it's a breaking change. I would consider that HTML private implementation detail and not matching markup from Bootstrap docs as a bug. But clearly documenting the change might be good anyways.

Yup, after investigating, I also can only see evidence of it being used for BS3 support. I've created a PR to remove the binding between the two

[SanderKnauff]

For the BsNav::Item and BsLinkTo I ran into an issue with the way parent/child lookups are being done.

In most of the new code, we pass through registerChild/unregisterChild functions from the parent to the child.
The old code relies on Ember for finding the nearest component of a type using the nearestOfType function.

Due to the way Bs::Nav yields children, it is not possible to have it exactly the same way in glimmer. Namely, the following situation will cause issues:

<BsNav as |nav|>
  <nav.item>
    <nav.link-to @route='application'>Dummy</nav.link-to>
  </nav.item>
</BsNav>

We have no way of telling the nav.link-to that it should register itself as a child of nav.item.

What should we do in this situation?

[jelhan]

Thanks a lot for investigating.

I think the root cause is that the <BsLinkTo> component is yielded from <BsNav>. But it should be yielded from <BsNav::Item> as it is expected to be used as a child of that one.

Changing which component yields <BsLinkTo> would be a breaking change. And would require touching all usages of it in all consuming apps. I would like to prevent that for now.

Would it be possible to register the <BsLinkTo> instances in <BsNav> and pass them as an argument to <BsNav::Item> for now?

[SanderKnauff]

I'm not sure if that is possible. If we have the <BsNav> register all link-to components, how would we tell which link is inside which <BsNav::Item>.

Considering the following situation:

<BsNav as |nav|>
  <nav.item>
    <nav.link-to>link 1</nav.link-to>
  </nav.item>
  <nav.item>
    <nav.link-to>link 2</nav.link-to>
  </nav.item>
</BsNav>

What could we do from the yield in BsNav to identify which item contains what link?

[jelhan]

Got it. Moving to <BsNav> is not possible.

I wonder if it is needed anymore at all. It seems to be used to set active and disabled CSS classes on <li class="nav-item">.

I cannot find having active or disabled CSS class on <li class="nav-item"> for Bootstrap 4 or 5 in Bootstrap's documentation. I can only find it in Bootstrap 3. In Bootstrap 4 and 5 the active and disabled CSS classes are on the <a> element, which is rendered by <BsLinkTo> itself.

Unless I missed something the code seems to be a leftover from Bootstrap 3 support, which we missed to remove. Would be great if you could double check as well.

Assuming I haven't missed something, I would recommend doing 2 PRs:

1. Removing active and disabled CSS classes from <li class="nav-item"> and all code related to it.
2. Refactoring <BsNav::Item> to Glimmer component, which should be unblocked after we landed the cleanup in first step.

I prefer two PRs to highlight the markup change more prominently in changelog. I don't think it's a breaking change. I would consider that HTML private implementation detail and not matching markup from Bootstrap docs as a bug. But clearly documenting the change might be good anyways.

[jelhan]

Thanks a lot to @SanderKnauff for implementing the @glimmer/component refactoring.