SyncRouterState delay

[adriaanwm]

Since updating to the new Router component, I needed the router values in state, so I used SyncRouterState. Unfortunately this has lead to a delay between the route values being in state and the component that is being rendered. For example if I have a user page /users/:userId and get the userId with useMapped state in the User component, the value will be undefined first, adding extra if logic (which is especially annoying when using hooks since you can't have any hooks after the if statement)

[staydecent]

@adriaanwm The route args are passed as props still: https://github.com/inputlogic/elements/blob/master/components/router/router.js#L236

function User ({ userId }) { ... }

[adriaanwm]

@staydecent this only helps if it isn't a nested component, unless I start passing props multiple levels deep

[staydecent]

Mmm, aren't most API calls related to current URL made in the "page" component though? And, if not, "dependent fetching" pattern should work? https://github.com/inputlogic/elements/tree/master/components/use-request#dependent-fetching

We could look into delaying rendering of the found route component in Router, until after the context/react-state is updated. But this would add significant complexity to Router.

[adriaanwm]

hmm, yeah you're right dependent fetching will solve the problem wherever the value is being used for a request. I feel like this is a bandaid soln in that every hook we build will have to accommodate undefined values otherwise we have to break things into more and more components in order to have if logic.
Agree that waiting for context will add complexity and probably more bugs to Router.
I'm getting the sense we're gradually moving away from the store being the source of app state, now it's spread between component state, context, and the store. My preference would be to keep pushing things to global store rather than away from it.

[staydecent]

Hmm, I don't know if I'd call it a bandaid solution. Outside of React, functions often need to account for null or bad values. I feel this is inevitable as a function is used in a wider array of situations.

The goal was to remove non-react dependencies from elements. Global store/app state is now explicitly managed via the pwa-starter code. This also allows us to move to any other state management library without having to untangle it from elements.

If it helps, I also don't think of Context as a state management layer, but rather just a transport/communication layer 😅 . State is only managed via react useState hook, but is communicated between components via Context.

Anywhoodle, I agree the delay in syncing is not ideal. Worth keeping this open to come up with ideas. I have one such I can test out today.

[adriaanwm]

I do like the decoupling dependencies (for me this includes react ones like context) from elements.
My preference would be to have a setup layer where you connect components from elements to your projects way of handling things like state. Something like this:

import { Router as RouterElement, match: matchBase } from '@app-elements/router'
import { store } from '/store'
import allRoutes from '/routes'

// match returns an object like {name: 'MatchedName', args: ...}
export const match = href => allRoutes.find(r => matchBase(r, href))

// RouterElement is only responsible for returning a component named `name`
export const Router = ({routes}) => {
    const name = useMappedState(store, W.path(['route', 'name']))
    return RouterElement({name, routes})
}

export const Link = ({href, ...props}) => {
   const onClickLink = (ev) => {
      ev.preventDefault()
      store.setState({route: match(href)})
   }
   return <a
      href={href}
      onClick={onClickLink}
   />
}

Store initial state would have to be a bit smarter:

import { match } from '/util/router'

const store = createStore({
    route: match(window.location.pathname)
})

This is brainstorming more than anything, I'd be happy to make this functional if you like this direction @staydecent

[staydecent]

I wonder if this is taking it too far?

I don't follow decoupling Context, when React is a dependency? These elements are all 100% intended to be used in React/Preact projects, with no allusion to being compatible with Vue, Angular, etc. Context is a decent API, as it allows using props without being limited to a passing props through a top-down tree.

This solution also puts a heavier load on the end-user of the elements. And, even requiring the end-user has a state layer they want to integrate with at all.

I think the timing issue can be solved, with either a nested internal component that renders the found route based on context, rather than directly in the Router component, or by exposing a new callback as a prop on Router, that can be invoked at the same point that setRoute is invoked internally.

Are there route args that you use other than to define an API request URL? How often do you access route args not within the matched route Component?

[adriaanwm]

1. Since we want the route values in store, handling the value with both Context & store increases js size & number of moving parts. The Router I'm suggesting is bordering on completely functional, it takes name and components and returns the matching component. We could include an example of how to use the router with context. There is also no race condition between the path and the route args in state because we are setting those values at time of path change.

2. I'm curious what criteria to look at to decide if an API is good or not. By my measures (namely explicit, functional, does not break basic coding standards, simple) hooks and Context are not good APIs. Especially hooks. The idea of only being able to call functions in a certain order without if statements would rightfully be turned down for any library other than React, I don't know why we or anyone else has made an exception. (hooks have been giving me grief so putting this here even though it's a bit of a tangent)

Also, avoiding dependencies should come down to more than what's included in an existing package (and for similar reasoning to the packages one). More moving parts, more complex, more lines of code etc.

"Are there route args that you use other than to define an API request URL? How often do you access route args not within the matched route Component?"
I don't think it matters how often route args are used in a nested component or in what way they're used. If we try to only handle the situations we can think of we'll be missing a lot.

I don't mean to brush aside the intention of having packages that you can install and they just work, I agree that should be one of our goals. I just think that shouldn't win out over everything else (especially how useful the package is for how we use it)

[staydecent]

Interesting, I think we have fundamental difference of opinion on this.

1. The current router clocks in at 10kb unminified. Reach Router is 20kb. Preact Router is 9kb but doesn't support nesting. If we want to have a nice website promoting that people use these elements (which I think we should), they should work with React out of the box. Syncing the router state doesn't complicate how the Router works, there is no additional "moving parts" introduced to the router. There is additional moving parts added to the host project. But, that's the cost of being able to swap state management at the project level, no?

2. Really? I think Context is a good API. It's functional, explicit, and only works by reference rather than a descriptive string lookup. The API is:

createContext => create a new context
Context.Provider => Provide the value for the context
Context.Consumer => Consume the value for the context

As for hooks, 100% agree the limitation of them needing to be called any every render (so not behind an if statement) is weird. However, beyond that, they are an improvement on Class based syntax. I also think you would find gotcha's unique to each front-end framework. I don't think that's good by any means, but it is the reality of front-end development.

I don't think it matters how often route args are used in a nested component or in what way they're used. If we try to only handle the situations we can think of we'll be missing a lot.

Absolutely, it matters. How else can we weigh the costs without understanding the real-life scenarios being encountered? For instance, in your project, are there 1, 10, 20 components relying on route args that are not the route component themselves? In other words, if this is an issue on 100% of the routes you have defined in your project, then there's more weight or merit to addressing this issue in a particular manner.

And, as I can't think of another scenario of needing the route arg to pass to a useRequest hook, I don't have the context to understand other current needs that need solving.

How can we decide if adding extra setup steps, writing more documentation, and adding more code to maintain in pwa-starter is worth it, if we don't analyze the current scenarios we are encountering?

[adriaanwm]

1. I'm not comparing our Router to react or preact router, I'm simply saying that if we're using a global store in our projects, and the lib uses context, that's more going on than a router that only uses one or the other. I would be all for separating the Router into something like BaseRouter where you have to handle the state things yourself in an intermediary file, and ContextRouter or just Router that uses context. They could be in separate packages or together. This applies to other packages like useForm where already having the state self-contained has been an issue for both me and Cory (and the reason for useForm: Add a setFormData to update form data at any time. #132 needing to be created).

2. I guess I meant more than just the API, but the implementation as well. Those functions look simple enough, but they are doing a lot under the hood to get that information from one component to another. I probably should have said "pure functions" instead of just "functions" since stateful functions are worse than pure functions, given all else is equal. At the extreme, a package that just has an API with one function createApp sounds great but only at the surface level.

Hooks may be a benefit over Class syntax, but I disagree they're a benefit over HOCs

Absolutely, it matters

Ok, I agree it does matter whether something occurs or not when weighing out possibilities. But when one solution handles essentially every possibility (the value is in global store, anyone can use it anywhere), whereas the other just assumes only a handful of things are possible, (you don't need route args outside top component) the one that's more versatile should be considered better than the other. And something like accessing the route arg from any component is not a crazy idea.

Another time to use a route arg is if you have a slug in the name and want to render the slug as a title while the actual resource is fetching. Or you need to use it in a form as initialData. Or you are using a third party hook and the id is used.

[staydecent]

Ok, that makes much more sense.

1. This is a nice approach, but I still wonder if it's worth the overhead of more integration code, additional work on the element, and more documentation to write 😅. I just tested out a prop based approach to syncing the router state:

export default function App() {
  const syncState = ({ path, route }) => {
    Object.assign(globalState, { currentPath: path, currentRoute: route })
  }
  return (
    <RouteProvider routes={routes} syncState={syncState}>
      <h1>App</h1>
      <Router routes={routes} />
      <Link to="home" activeClass="active" className="home">Take me home</Link>
    </RouteProvider>
  );
}

☝️ This works by adding ~2 lines to router.js and will call the syncState function before the internal setRoute, which should sync the state to the global store, before rendering the matched Route Component.

2. I agree with what you are saying 100%, but Context is actually a rather simple Component factory: https://github.com/preactjs/preact/blob/master/src/create-context.js

Hooks vs HoC is interesting. HoC implementation is better, but hooks are "de-facto" in react world now. I think it's ideal for our code to not deviate too much from the "broader react community".

Even we if did decide to favour HoC's, we would, at some point, reach for 3rd party libs that would provide hooks. So, we'd have to be familiar with both anyway. In such case, is it better to only encounter hooks in our projects, or mostly HoC's and sometimes hooks? Is this point worth considering withRequest instead of useRequest?

I think the more versatile option should be considered more versatile. But that doesn't mean it doesn't come with a cost (more functions exported, more docs needed).

	BaseRouter	syncState
Pros	100% Global state control	One prop to learn
Cons	Splits Router into 2 exports	Cannot override internal state
	Requires more docs/code in pwa
	State values should have checks/guards since they are coming from end-user rather than internally

I'm sure I'm missing cons for syncState, but that's how I see the two options currently.

[staydecent]

Also interesting is react-navigation and react-router both recommend against integrating routing state with Redux...

https://reactnavigation.org/docs/redux-integration#can-i-store-the-navigation-state-in-redux-too
https://reactrouter.com/web/guides/deep-redux-integration

[staydecent]

I think this whole discussion can be attributed to the Use/Reuse Paradox.

A module or service might be highly reusable, but very difficult to use. Likewise, a module or service might be very easy to use, but difficult to reuse. And it’s incredibly difficult to offer both.

Reuse being the ability to make a derivative, and use being embedding the module in a project. I am advocating for ease of use over ease of re-use. Not just to make the project more friendly to the public, but to also reduce the configuration required within pwa-starter. I think pwa-starter should be as close to "just folder structure" as possible.

Because of this, we should strive to minimize the architectural significance (impact and cost) of change by making our designs as reversible as possible.

To me, exposing props will be a less intrusive or disruptive change than breaking Router into a Stateless export and a Stateful export. I also am not convinced we should allow internal state to be set from outside of Router, as I tend to agree with react-navigation that it introduces surface area for creating bugs.

The delay in the ability to sync the internal router state to an outside source, is one worth fixing. But I think we should fix it, without compromising the usability of the element.