Is it possible to use this library without taking a dependency on redux?

[kimsagro1]

Firstly, this looks like a amazing library, so thanks for all your hard work !!!

We are currently using mobx and are looking to use this router, however I we would prefer not to take a dependency on redux.

Is there a reason this library takes a dependency on redux rather than providing redux support as a seperate package. For example react-router and react-router-redux?

[taion]

This library actually uses Redux internally for state management.

That said, I'm curious why the Redux dependency matters. It's a dependency rather than a peer dependency, so if your project does not itself directly use Redux, then the dependency is essentially invisible to you, outside of maybe showing up in your lockfiles.

For reference, that's exactly how we use Found – we use Relay for all of our state management and do not directly use Redux at all.

[kimsagro1]

Apologies, I assumed incorrectly that this could only be used with redux.

Thanks for clarifying, I will close out the issue

[ignatevdev]

It's been more than 2 years now since this issue was created. React has advanced a lot and with the introduction of hooks and new context API it seems that redux dependency can be dropped in favor of the react's built-in utilities. This should significantly decrease the bundle size of found and in my opinion it's worth considering.

@taion What do you think?

[taion]

@ignatevdev Do you know if there's a good pattern for libraries that don't use Redux to integrate nicely with Redux? We have a few places where we have middleware that works on Found actions, and it'd be nice to keep that pattern working.

[ignatevdev]

Good question. I don't remember the last time I've worked with a library that offers redux integration. The only example I can come up with is probably react-router, but the way it worked was not ideal, because it was more like a synchronization than integration, which sometimes may cause edge-cases because internal and redux states are out of sync. Other routing libraries seem to follow a similar approach, but I haven't checked them all.

However, it seems to me that with the right architecture that shouldn't be that difficult to implement.

Initially without redux we would need:

• Our own routing context
• Our own reducer and actions

The context will store the current routing state and the callbacks, such asmatch and router. Routing state will be derived from the reducer and callbacks will only trigger dispatch with an appropriate action. useReducer will implement the reducer and useContext will replace the connect and useSelector.

Then, if we want to integrate with an external store, which might but not necessary be redux, we only need to pass through the current state of the reducer and action dispatcher. When a routing callback will be executed, external store will be updated and the new state will be passed through.

I hope I've described my idea well enough. Let me know what you think.

[jquense]

TBH the value of redux here is less that it integrates into ones app, I don't think we've ever needed routing state outside of the context of the component tree (perhaps tho that is a side effect of Relay forcing us to stay in it to do most things).

The larger thing is that redux's middleware stack is doing all the heavy navigation logic and i'd imagine porting that to something else would result in something like redux middleware, but not shared by anyone which seems less ideal.

[taion]

We could potentially drop React-Redux, as we're barely using it... but I'm not really sure it'd get us much to do that. Bundlephobia says it's only 2 kB minified + gzipped...

[ignatevdev]

It would be perfect if the middleware layer wasn't tied to any vendor library and was replaceable at the same time. Something like the current resolver implementation. Default resolver implements all the general features while a custom resolver can be used to integrate with other libs such as relay.

This would decrease the bundle for apps which don't need/use redux and allow for other store libraries to be integrated into found.

Is something like this possible in a reasonable amount of time?

[ignatevdev]

It also seems that some people have already tried migrating their redux middleware to useReducer, hence something like this is available: https://github.com/shiningjason/react-enhanced-reducer-hook

[jquense]

I think picking one library for another doesn't ofter much here. It's only worth ripping out if we think the byte savings out weigh the cost of maintaining new bespoke, less battle tested code, which I think is still unclear.

[ignatevdev]

Yes, you are right, adding a new dependency is not good at all, but my point was different.

If you look up the source of my example you'll see that it's only 28 lines of code, which can be easily borrowed to found/farce and replace the whole redux among with react-redux with almost no cost.

[taion]

I think we partly could... the issue is that Found and Farce also use store enhancers, though. I'm really on the fence here. I think there are people who use this library with Redux (including 4Catalyzer), and the idea of fully replacing Redux here is perhaps... just not particularly useful to users? Does your dependency tree actually fully exclude Redux and React-Redux?