Open dougy-fresh opened 1 year ago
This is particularly difficult because the way we communicate theme contexts is using the method proposed in the protocol suggested by @benjamind . This uses a callback to pass the context, which can't be intercepted in the same way an event might.
Not sure what you mean. Context protocol is explicitly event based and supports use cases like having multiple separate DOM trees serviced by different context providers.
@benjamind I thought about this some more after you left this comment, and I think I understand what you're saying.
We were discussing a component one of our designers made that has two halves of a screen -- the top, which is the light or dark theme, depending on a user selection, and the bottom, which is the other theme. If I understand correctly, to implement this, my components in both sections will fire the event requesting the theme context, but the inverse section will have its propagation stopped by "theme inverter" component, which listeners for events from the root contents, and emits the theme values for the inverse theme in place of the regular theme values?
I was thinking of trying to interrupt the values as they are passed along the callback chain instead, which I think is where I went awry. I was thinking we'd have to call a chain of callbacks so an intermediate could change the theme value after we've initiated a theme change, but that's far too late -- I need to have already set up the context providers correctly by then.
We sometimes want to have one theme for half the page, and another for the other half. How can users intercept the theme context provider to substitute another value?