mariusandra

OP here, so call me biased, but I tend to disagree. Curious to hear your thought on alternative or better approaches to system design here.

In my experience you need some amount of boilerplate, or what I'd call _architecture_, to have a stable system. Give too much freedom ("just use get/set" or "variables on context"), and not only can no other developer on your team not maintain your code, but no part of your app will work together after a while. You'll end up with multiple incompatible implementations of ad-hoc state machines.

The key to maintainability is to use a framework that forces you to do spend a bit more effort than you'd do when coding YOLO, but which forces everyone on the team to make the same tradeoff. The result: everyone can jump in to any part of the project and with a bit of digging around be fluent in the surroundings.

Kea seems to strike a pretty good balance of making this possible in large projects.

In the approach described in the blog post, you only need two use*: `useValues` and `useAction` to pull in values and actions from the data layer. Nothing else. No local state with `useState`, no `useEffect` or `useRef` or anything else for interacting with your data. So in effect React == two hooks and JSX.

Something that comes for free with Redux and its abstractions like Kea (the approach promoted in the linked blog post) is that you mostly avoid the problem of needless re-renders.

Each `useSelector` call (and `useValues` call that uses it) triggers a re-render only when the value changed. So unless you have something forcefully re-rendering the root node, only the few relevant sub-sections of the page will re-render.

It's not perfect nested-sub-object level precision, but in practice works well enough.

Agreed that if your frontend is mostly GraphQL, and your data flow well taken care of, you shouldn't see a need for a separate state management solution.

However sometimes you have to work with various APIs and filter/display/modify/update/delete/change/patch various parts of the responses you receive. That's the environment where solutions like Kea (mentioned in the blog post) come into their own.

Hey! Thanks for the comment and that's really cool! Your product looks really slick as well!

Would you mind posting in this "who's using kea" issue about versoly as well?

https://github.com/keajs/kea/issues/35

I'm someone who through sheer coincidence (the right projects at the right time) happened/lucked into developing a React state management solution (https://kea.js.org). I've probably sunk hundreds of hours into this project by now.

5 hours before this HN post I asked for comparisons with different site management libraries on Github here: https://github.com/keajs/kea/issues/106

React state management is indeed a mess, meaning there are so many options to choose from. Unfortunately, even for me, a library author, it's hard to evaluate all of them properly. It would take just too much time and you never know where the real problems in any framework lay before you get neck-deep in code. And then you're too far to switch to another framework anyway.

Someone should really map out this landscape in more depth than just an awesome list. I hope the issue linked above can spark some discussion.

In any case, I personally think Kea is a very good solution for React state management, yet obviously I'm biased. Shrug.

And, to keep it on the topic, Recoil seems very low level and I think you need to invent a lot of things yourself to get a full app out of it. Cool to see people trying stuff though :).

And it's from Facebook so who knows, just by proxy it might become the default "atom" and someone will build molecules out of them...

Hi, that's a good point! This was also not an accident.

Insights started life as a Rails app, but I wanted the portability that being a JS app provided, so I rewrote it. Back then I just wanted it to eventually get it running in Electron.

Now it's an app running FeathersJS [1] and CreateReactApp [2] under the hood.

[1]: https://feathersjs.com/

[2]: https://create-react-app.dev/

Ah, my apologies! Thanks for clearing this up!

And to add, regarding the feature requests:

- OpenID support is definitely on the near term horizon. I actually need Google Oauth support for myself... and adding a few other providers, including OpenID will be part of that development. Ldap, I'm not sure... perhaps one day, but having that won't scratch my own itch and we're still in the early days.

- Insights has a full API for communication that is used by the frontend, including for creating/saving charts and soon for dashboards. Userless API access is also one of the next things in the list... and with that you can create as many charts/dashboards as you would like. I personally already use the insights API in my work's backend for autogenerated graphs. The backend Rails app talks to Insights and passes the data returned to the "insights-charts" package, which embeds a React graph our admin backend. The only thing needed is to copy the query (button in the top right) and modify it as needed before making the request for chart data.

- Import/export would indeed be good to have!

Hey, thanks!

Regarding Metabase, Insights has full blown first class support for joins... so we don't have to write blog posts like this [1]. My research shows Metabase works great with normalised tables (like a CSV file? normalised NoSQL table, etc)... but falls short when you need to visualise relations between tables. You can look at for example all your orders, think "I wonder what's the highest grossing country" and have the results at your fingertips.

Regarding Redash, which seems to be a nice SQL editor, in Insights you don't need to know any SQL to get answers. Thus "business stakeholders" can get dirty with the data with minimal training.

Regarding Superset, I'm unfortunately not familiar with its latest features. Please somebody reply with an overview! :) Last time I checked it (many years ago), it was pretty complicated to get it installed (some python issues?) and I'm not sure if you could explore data without knowing SQL. Insights in comparison is super easy to install (npm install -g insights) and get going with.

[1]: https://www.metabase.com/blog/Joins/

Hey, thank you for your kind words!

I've been putting a lot of effort into the UI/UX lately and it's great to see it paying off... even though there is still so so much to improve.

We actually already have support for calculated fields! Just edit a "subset" and you can add as many custom fields as you would like. [1]

Thanks again for the feedback! :)

[1] https://user-images.githubusercontent.com/53387/74677547-e8d...

I can assure you, that's a bug and not an intended feature.

Thank you for your feedback.

This is very unfortunate, even through the writing was on the wall already for a while [1]

I used LoD often. It was just perfect for on-the-go javascript hacking. In fact at least 200+ commits to the Kea project [2] were written with Linux on Dex.

The only issue I had was that with larger projects [3] when running in the Mate desktop environment, I quickly ran out of inodes... and there was no way to increment them. I had to turn off many things in vscode (file watcher) and my projects (recompile on change) to have an usable system.

Time to look for alternatives. In the worst case I can just connect to a VNC server somewhere (LoD also used VNC), but that requires constant internet access and has issues of its own. LoD was just perfect for quick code writing in airplanes, etc.

[1] https://www.sammobile.com/interviews/dex-product-manager-new...

[2] https://kea.js.org/

[3] https://github.com/mariusandra/insights

For apps written in React, try pigeon-maps: https://pigeon-maps.js.org/

You'll need to find a tile server though. What to choose depends on your volume. Mapbox is the provider with the best tile quality to price ratio as far as I can tell...

Unfortunately I have no access to an iDevice for the remainder of the week as I'm traveling for work. If anyone can help debug this and perhaps even submit PRs, it would be greatly appreciated!

If you need support for all that leaflet provides, go for leaflet. If the feature set of pigeon-maps is enough for your needs and you already use react, feel free to go for it instead.

I have never claimed it to match the features of Leaflet while being lighter. It's lighter exactly because it doesn't. Offloading a lot of DOM work to React makes it even lighter.

Edit: to correct one point, pigeon-maps does support mobile.

This library is made for sites that already use React.

Exactly! This project is for apps that already use React and need to add maps.

Alternatively, you can try preact [1] or inferno [2] and for a few KB more you have something that is still smaller than Google Maps or Leaflet.

Of course if you need more advanced features and geometric calculations the size can go up considerably. Leaflet and Google Maps provide that out of the box. Pigeon-maps doesn't.

[1] https://preactjs.com/ [2] https://infernojs.org/

Could you describe what you experienced in more details? Scrolling with a mouse? Trackpad? Touch? Could you quantify "goes to hell"? The more details the better of course. Thanks! :)

Demo updated, thanks!

I only use React. The Inferno support was added 2 years ago when an issue requested it, as I was evaluating Inferno support myself at the time. Since then I haven't done anything with it.

Unfortunately not. Currently vector tiles are outside my personal scope for the project, but I of course welcome PRs.

Hi, I added attribution to the Mapbox maps. Please reply if any of the others are wrong as well.

Well, there's the github commit history, that sort of answers the question, no? :D

Otherwise no, there is no write up of the process. I might do one some day, thanks for the idea.

Thanks! I added a link to the github page on the demo.

And for the checkbox buttons... oh well :D

Hey, author of Kea here. I'm always very interested in feedback as well! :)

So strken, acemarke and others: Feel free to reply here, contact me on reactiflux (@mariusandra) or shoot me an e-mail if you feel like talking about Kea.

Cheers and thanks for all the nice words so far. :)

They are in src/__tests__

Hey, thanks for the comments/feedback!

For the library-depth spidey sense, there's really no getting around that. In a way, as React itself is just the view library, you're forced to add new pieces to your app until it all clicks together. Kea is just one more of these pieces... And I wrote it so the other ones would click together. The alternative to abstracting libs like that is to write and bundle everything yourself, but that is a hard and, in this case, unnecessary path to take.

Two of the libraries it abstracts (redux and reselect) are as stable as a rock. There have been no breaking changes for many major releases. The third one, redux-saga, is a bit more brittle, but as it gets passed direct control over its domain, I don't see how kea would break anything there, at least not in the near future.

Of course I'll do my best to keep up with new releases of all dependencies. I do have a few apps with Kea that I actively maintain.

There's still the chance that Kea itself will change drastically. I hope not. I'm actually trying to stabilise the API for a 1.0 release.

But that's kind of the point with react: it's just a view library so you're forced to add things to the tech stack until they click together. Of course it helps a lot of you know how all the layers work on their own.

If you use something like Kea (https://kea.js.org), the amount of boilerplate for Redux goes down dramatically. The syntax is actually pretty simiar to Vuex, perhaps with even less boilerplate.