I think Node.js should probably be the first place to reach for when building interactive front ends that need to talk to a backend... The iteration and throughput you can get with node initially make up for most of its' shortcomings. That said, you can always shave off pieces that don't perform well into services that are farther back, then use node to delegate the operations from your front end to these more performant services.
As TFA mentions, structure and discipline are important as projects grow... It's easy to create a mess of spaghetti.
I would say if your data set is hundreds thousands of records, JS and Node can be *very* bad at this... In general, when trying to map-reduce larger data sets in node, you need to really be careful on how you introduce, stream and dispatch results.
Node has a command line flag that can expose manual garbage collection (good to do after each record, or every N records, as memory use will grow fast otherwise. Even then, when you have so many objects referenced, they will collapse... You can use streams for the map, and reduce aggregates, but if your reduction aggregate object/map gets too big, it will blow up the runtime when you run out of references and/or memory available.
Realistically go and even rust are better suited to these kinds of flows with larger data. I love JS, it's my favorite language, and I really like node... but there are some use cases it's absolutely bad for.
As far as I'm concerned local is langage + location... such as "en-US", where language-only is a fallback if there's no match in language-location.
I would probably either have a "default" language, or a configuration to set what the default is. With rules for fallback/forward.
I'd also get rid of the configuration option to specify locales, and use the directory path's /^(default|([a-z]{2})(\-[a-z]{2})?)\.json$/i to look for configured localizations. This means less configuration, and more straight forward defaults.
Minor niggle, I would make the action's payload itself the Promise... as it is, one has to dig into it... There's no reason not to simply check for a thenable payload directly.
The modal itself presents a single issue I see a lot in modals... in that if the vertical space on the screen doesn't show correctly, the modal won't scroll, also, the page in the background does scroll[1].
I generally put in the effort to work around this.
[1] https://github.com/juanbrujo/tinyModal/issues/4
IIRC, flow doesn't/didn't work on windows, which is a non-starter for a lot of users... not sure where this stands now, last looked at it when using flow types to be able to use angular 2 without typescript, as I mentioned, I didn't see the point as I still needed bits from babel.
But flow adds type support (same as typescript), and can also be used with babel... flow only does one thing, so better integration. Typescript doesn't offer much beyond types (and flow does that) over babel.. and as you say, you're using babel anyway.
Because at runtime, typescript doesn't provide type checking... ie: when interacting with a foreign API... Beyond this, with small, well-organized modules, TypeScript tends to only add boilerplate, and doesn't tend to prevent as many errors as the time to write boilerplate prevents.
I can see why some would like it, I just don't find much value in it.
I'm going to agree with several of the comments that async/await sugar around generators would have been more welcome than non-nullable types.
Then again, I kind of find TypeScript itself of questionable value over es2016 + stage1 via babel.
As far as I'm concerned local is langage + location... such as "en-US", where language-only is a fallback if there's no match in language-location. I would probably either have a "default" language, or a configuration to set what the default is. With rules for fallback/forward. I'd also get rid of the configuration option to specify locales, and use the directory path's /^(default|([a-z]{2})(\-[a-z]{2})?)\.json$/i to look for configured localizations. This means less configuration, and more straight forward defaults.