Closed olizilla closed 6 years ago
Hey @olizilla, it's been a while since our paths crossed, hope you're well! Thanks for this, I like it! Just to preserve the option of passing other options here later, I think I'd rather do this as an option object. Also, we should add a note about this in the docs.
@olizilla published as 21.2.0
thanks! Also... out of curiosity what are you using this for and what do you think so far?
Rad! Credit where it's due, I was paring with @alanshaw on prototypes for a rebuild of the ipfs webui when we hit this and figured out a solution.
I've tried redux in the past and found the boilerplate added more friction than value. I fell into the trap of derived state in the tree, and trying to use it along side other sources of truth like react-router or meteor collections, and it never seemed to be a good fit.
I've built a large app using just setState and passing props down, and with some discipline you can get a really long way, but the app is now sufficiently hairy that the idea of a significant refactor now fills me with some dread.
So redux bundles feels like a good path forwards. My first feeling was "there is lots of magic string magic here" which gave me concerns, but I'm all for convention over configuration as things and teams grow. The idea of properly separating the app logic from the presentation, and the mental image of being able to pull away away the mask of the presentation code and see the whirring cogs of the app engine still going was the strongest motivator to keep going. That and the radical reduction in boilerplate.
We thrashed around some on how best to manage a bunch of live updating stats that involve polling various endpoints every few seconds. Right now I've extracted the APP_IDLE logic from the reactors bundle into it's own bundle that I can tune without having to switch to composeBundlesRaw. The plan is to make it dynamic when I get time, so that I can dial down the idle interval when the url is /stats.
It's very early days, but the starting point for the new react-bundler based IPFS webui is over here https://github.com/ipfs-shipyard/ipfs-webui/tree/revamp
It has a interesting set up in that the "api" is a IPFS daemon that runs (typically) on localhost. The work of fetching files from remote peers is handled by IPFS, but we still want to be robust to the local daemon getting shutdown, or requests taking a long time when peers are hard to find.
By letting the user pass in the selector to use to get the routeInfo they can override the default with
selectHash
, which allows hash based routing in their app.e.g.