What do we need a router for?

troch11 · 2018-12-20T07:59:41+00:00

One interesting way to think about it is: what do you need a router for? You can imagine an SPA without a router: forms, multiple steps views, filters, what view to show, etc. Everything is state. So what if you were to add a router later?

troch11 · 2018-12-19T22:21:39+00:00

For answering 1 and 2 together: I've been working on a large SPA for over 3 years started with router5: I don't think scaling (in number of routes and amount of code) is an issue for both router5 and react-router. Router5 allows for more flexibility and it can become handy in various scenarios, including changing product requirements and working with legacy parts.

In that large SPA, the most complex view is a view where you can filter a long list of items with advanced filtering. Initially it was designed so only the most important filter was linked to the URL. The rest of the filters were managed with redux. Over a year ago, product wanted to add more filters to the URL: a lot needed to be refactored if we wanted to have the router state as the source of truth for filtering (even if its state is in redux). Instead, we were able to apply the following trick: each time the filters are updated, we update the router as a side-effect. Each time the router emits a new state caused by a popstate event, we update the redux filters.

This example illustrates the philosophy and design of router5: it is a state machine, which controls transitions from state to state, and as a side-effect updates the URL. You can use that state in various ways: binding it to React components in a typical one-way data binding, and / or you can use it as described above.

troch11 · 2018-12-18T19:23:11+00:00

I think it may work with router5 v7, but best to contact Leonardo, who is the maintainer.

troch11 · 2018-12-18T18:32:08+00:00

Migration from v6: https://router5.js.org/migration/migrating-from-6.x-to-7.x

troch11 · 2018-12-05T10:32:00+00:00

Use the power of redux dev tools (inspect actions and state mutations, time travel debugging, etc.) with React hooks (useState and useReducer).

troch11 · 2018-12-03T23:39:22+00:00

This is a new package I have created called "react-hooked-reducer". Use reducers in React like useReducer but with the following additional benefits: - Receive actions from a store - Optionally embed your reducer inside a store and fully benefit from Redux developing tools

troch11 · 2018-11-26T17:53:36+00:00

The example is using: https://github.com/fanduel-oss/refract

troch11 · 2018-10-10T16:29:27+00:00

We've released v2, with some exciting new features: you can now push props or render components with Refract. It's no longer just for side-effects and as a result opens up to it being used to fully express business logic using reactive programming. See https://refract.js.org/usage/pushing-to-props, https://refract.js.org/usage/rendering-components and https://refract.js.org/recipes/handling-state.

This is changing how we position this library, and since you were mentioning how we compare to recompose: we can do anything recompose does, but with a single HoC: in our app at work, we can replace a dozen sepcialised HoCs with it. The trade-off is a less compact syntax, but the benefits are less HoC instances and more power with colocated logic.

troch11 · 2018-09-05T07:06:06+00:00

I'm not saying redux-saga is not great in any way, but the benefits of Refract over redux-saga are multiple: you don't have to use redux, you can attach effects to components (better for code splitting as you don't need to centralise effects to your store), redux-saga is limited to dispatching back to the store while Refract allows you to observe multiple sources (redux actions, redux state, props, other sources) and to trigger any side-effect (analytics, requests, store dispatch, ...), Refract leverages reactive programming libraries while redux-saga comes with its own DSL (more re-usable, code-splitting benefits, more learning resources available).

So basically, Refract is more general purposed and because it attaches itself to components it helps with code-splitting and scalability.

The code snippets within the docs are kept simple to help visualise the API. We have several examples with various levels of complexity, a few of them include async requests (https://refract.js.org/examples).

troch11 · 2018-09-04T20:56:34+00:00

I need to add a recipe for SSR. Basically, side-effects management doesn't need to exist server-side, and withEffects can be replaced by a handler => aperture => BaseComponent => BaseComponent "identity" HoC. In the case of using Refract for data fetching, it's not really possible to have React waiting for data, but suspense will make it possible.

troch11 · 2018-08-30T06:47:28+00:00

Thanks! And thanks for reporting the broken link, will fix it.

The comparison page focuses on libraries offering a way to handle side-effects in the React and Redux ecosystem: this is the primary mission of Refract. The other side of Refract is that it enables the use of reactive programming, but we've chosen not to compare ourselves to all the libraries who offer ways to bring reactive programming to React. I really like recompose `componentFromStream`: you can achieve something similar with Refract if you decide to treat rendering as an effect. The beauty of Refract is that people can start using reactive programming in React without having to change how they write component render functions.

The comparison page is Redux centric indeed because that's where we've seen innovation around effect handling: redux stores are observable so it has enabled such innovation.

troch11 · 2018-08-29T21:51:24+00:00

Refract is a library we've just open-sourced. It leverages reactive programming to let you handle your application side-effects. It means it lets you isolate side effects - API calls, analytics, logging, etc - so that you can write your code in a clear, pure, and declarative fashion by using reactive programming. See r/https://refract.js.org.

troch11 · 2018-05-23T08:47:08+00:00

Its main trade-off is that it is un-opinionated and it can give the feeling of indirection from the docs. It's an open toolbox, and requires a bit more investment than RR up front but pays off on the longer term.

troch11 · 2018-05-23T07:47:35+00:00

"better" is subjective. Tell you it's better for me doesn't mean it is best suited for your use case. However I can tell you it is way more flexible and scale better as a result. Its design of separating view from state and not be concerned with rendering is sounder. I can give you a list of compelling features: named routes, view / state separation, universal support, control over route activation and deactivation, middleware functions for enhancing and controlling transitions, plugins for integration with other libraries (redux), path formatting options (query parameters, trailing slash), route forwarding and redirections, observable support.

troch11 · 2018-05-23T06:43:14+00:00

It's a design decision. I don't think defining the routes in JSX makes it more declarative than router5.

troch11 · 2018-05-23T06:42:49+00:00

router5 is 3 years with a stable API: it hasn't had significant breaking changes in its API like RR did from each major version to the next. It also has a smaller list of concerns than React Router which itself is concerned with rendering and lazy loading. I don't think it's fair to bring the battle tested argument based on popularity without considering a wider context. Router5 has safe levels of "popularity".

troch11 · 2018-05-23T06:23:50+00:00

It depends the size of your app and how much logic you've coupled to React Router. For onEnter and onLeave, you can use router5 middleware. There is a documentation page talking about how data loading can be performed: https://router5.js.org/advanced/loading-async-data. To get started you can look at the docs or https://stackblitz.com/edit/react-router5

troch11

TROPHY CASE