Hello, thank you for this library. I am switching from react-fill-slots library to yours, because of keeps updating with the new ReactJs version. I am trying to solve one problem. Let me give you an example.

This is my component where I am using Fill with name Sidebar.Content

`export default function Sidebar({ label, order, children, renderDontFill = false }) {
  const content = (
    <Section order={order}>
      <Header>{label}</Header>
      {children}
    </Section>
  );
  return renderDontFill ? content : <Fill name="Sidebar.Content">{content}</Fill>;
}`

This is my component where I am using <Slot name="Sidebar.Content>

function Sidebar() {
          <SlotsProvider>
              <Slot name="Sidebar.Content">
                {(elements) => (
                  <div>
                    {elements.sort((l, r) => (l.props.order || 1000) - (r.props.order || 1000))}
                  </div>
                )}
          </SlotsProvider>    
  );
}

if content In Sidebar is more than one it always displays the last one. In previous library react-slot-fill there is functionality of getting byName which returns Fill[] . Is there a way to solve this with your library ?

The Fill frequently needs to access data from the Slot to render correctly, so not having some means of doing that(similar to params in react-view-slot) is problematic for our use case.

Is there some way to achieve this that I'm missing?

The package peerDeps specify react 16/17 only.
This fails on recent npm unless --legacy-peer-deps is used.

I am here to say Thank You for the awesome package @exah

Hello,

We use react-router v6 which supports relative links. In order to make it works properly the components need to behave like they do when rendered as a Portal. So no matter where they are physically rendered in the DOM they still follow the virtual tree structure and have access to any context wrapping them.

I noticed that this library is breaking this behaviour, so we can't use relative links in components "sent" in our Layout.

Do you think there could be a way to match Portals in term of Context consumption?

I'm pretty sure there are issues with the way that null state is tracked for Slots.

This issue came up in two specific situations.

1. Let's say we have SlotA and SlotB and then a single Fill. If the fill is rendering into SlotA and then I change its name so that it renders into SlotB, Both SlotA and SlotB have the fill content rendered into them.
2. If have a component that renders a Fill, and then just returns null(where it's no longer rendering the fill at all) the Slot holds on to the fill content.

I see that you have onChange, but it doesn't get called on the initial render. Is passing context up the tree from the components that render the fills the only method I can use to figure out if a slot has something in it?