Onto the more serious problems. There’s the big fat obvious one that this uses Proxies, so no IE11, no Safari 9, and no Blackberry Browser! How will people that work in the payroll department of federal government agencies use your website!

I think maybe you could get it to work without proxies using some fancy footwork and constructing objects with getters and setters. But not in 160 lines of code and not in one weekend. So I’ll leave that to someone else.

(See how I classy-bragged that I made this in a weekend? That’s why they call me the smooth-meister.)

There’s also risk of confusion here. If you pass a task object to a child component, then it’s a reference to the object in the store and you can update it, but if you pass the task name, then it isn’t a reference and you can’t update it.

I wonder if — in a large app with developers of different skill levels — this would become frustrating, or something you’d get used to.

And, is it a bad thing that you can access the store from anywhere? The voice in the back of my head says “gee it’s dark in here” but also “restricting things is good”, but I can’t put my finger on why.

Ah, and also I’ve done very little testing. I’ve tested it in Chrome and Chrome and nothing else. But I did convert my current side project to use Recollect. It’s quite data heavy, has thousands of DOM nodes, and is purring like a kitten.

Also, this relies on React rendering in a particular way for Recollect to be able to ‘record’ components retrieving data from the store. If React version 17 were to change that for some reason, this could all unravel like a ball of wool being attacked by the kitten from the previous paragraph.

Performance

This was a bit disappointing. I expected this to be heaps faster than React with Redux, or even React with component state.

But in my tests, Recollect and plain old setState on a parent component were about as fast as each other. To be fair though, even with 2,000 DOM nodes, they were both updating in 40ms. So I clearly need a bigger app to test on.

I suspect that the bigger the app, the bigger the performance gain you’ll get from Recollect. But then I would say that, wouldn’t I.

File size is an interesting one. It depends on the app, because if you’re replacing hundreds of lines of reducers with this tiny thing, your file size will probably go down. In my relatively small app (that didn’t have Redux), my total JavaScript size went from 38.9 KB to 39.3 KB after adding react-recollect and removing all the reducer-type logic I had.

So if you wanted to come up with a particular number, you could say that Recollect is something like 1 KB. But really, it’s likely to make your app smaller.

So, what next?

I’m still riddled with self doubt about this. I’m quite certain I’m not the first person to come up with this approach, so I figure one of the following must be true:

The fact that browser support is less than 90% means it’s of no interest to the real world, so no one’s ever pursued the idea.

The idea has some some serious problem I haven’t thought of.

It has been done, it’s a popular library, and I haven’t come across it because my narrow mind dismisses anything that isn’t React+Redux.

And I purposefully haven’t looked for tools that do this; I’m more interested in exploring than being a productive member of society.

Yet the dread of prior art looms large. If you’re aware of a library that did all this four years ago, you could play a fun prank on me by not telling me about it in front of all my internet friends.

Edit, one day later: “Congratulations, dickhead, you just re-invented MobX”.

Although to be fair (to me), it’s not exactly the same. With MobX it seems like you have to say in advance which props you plan on using in a component and define them as ‘observables’. I’m sure there’s a good reason for this, but as an API minimalist, I like the idea that with Recollect you don’t need to worry your pretty little head about concepts such as observables, it all gets worked out behind the scenes.