The team is now working on the WordPress Interactivity API. This unblocks the same UX Frontity framework enabled but directly in WordPress Core, fully compatible with the new Site Editor.
@Segun, as we talked today a little bit about improving the way routing works in Frontity, would you mind sharing your impressions about this Switch component? Do you see any limitations? Would you use a different approach?
iamuchejude3
@luisherranz What’s the plan for this? Can we have a call to talk about it? I would love to work on it.
luisherranz4
Sure! Let me know your questions
mmczaplinski5
Have you discussed any further details @iamuchejude@luisherranz ?
luisherranz7
@iamuchejude can you give us an update on this? How is it going?
iamuchejude8
@luisherranz The work on this feature has been going well. After hours of contemplations and researches on how it should work, I was able to write a component whose children accepts in either of 2 props; that is, either path (URI path) or when (boolean) props to conditionally render the children components.
Usage
import Switch from "@frontity/components/switch";
const TestSwitch = ({ state }) => {
const data = state.source.get(state.router.link);
return (
<Switch>
/* With 'when' prop */
<Loading when={data.isLoading} />
<Archive when={data.isArchive} />
<Error when={data.isError} />
/* With 'path' prop */
<CustomPage path="/custom" />
/* WIP: The last component without props should be rendered if no matching component was found (404) page */
<ErrorComponent />
</Switch>
);
}
At the moment, I’m trying to figure out a better way to handle errors (The current implementation doesn’t seem to handle edge some cases) with the switch components. The path prop will also need a review before I’ll proceed with fixing the issues with it.