[xab9]

Well, typescript is nice. But. The amount of boilerplate I write with redux is downright annoying, add typescript to the mix and the interfaces, typedefinitions, enums, various scattered exports, actioncreators and typehelpers are just mind-boggling - I don't like it.

Heck, I already have huge livetemplates in my ide to generate most of these stuff, but it feels wrong. And while we have fun writing "enterprise quality code", routing falls apart, load indicators are missing, form validators are a mess, error handling is broken, etc.

[acemarke]

Hi, I'm a Redux maintainer.

We're currently working on a package called `redux-starter-kit` that contains some utilities to help simplify common concerns about Redux, including store setup, generating action creators, and writing reducer logic and immutable updates:

https://github.com/reduxjs/redux-starter-kit

I'd appreciate it if you could take a look, try it out, and give us some feedback.

It's currently JS-only, but we're planning to convert it to be written in TS in the near future.

As for as Redux and TS in general... I know I've seen comments similar to yours ("duplicating action constants and enums", etc). Unfortunately, I don't use TS myself, and don't know enough to offer meaningful suggestions there.

If you've got specific pain points with Redux and TS, please go ahead and file an issue for discussion, and perhaps we can work on some solutions.

[zawerf]

I recently started looking at mobx-state-tree[1] and I feel like it solves a lot of the boilerplate needed with redux in a very nice opinionated way. In particular it has built in support for tracking action history (as list of patches and snapshot), building views of computed values (selectors), organizing async action flows, and colocating all of this logic in a single model class.

It can be used on top of redux but it won't really look like redux code anymore. But since you're using immer in the starter, it wasn't going to look like redux anyway (e.g., ton of triple dots everywhere).

Do you have any opinion on mobx-state-tree? Maybe you should just bless mobx-state-tree in the starter too? (immer is built by the same mobx guy)

[1] https://github.com/mobxjs/mobx-state-tree

(I have not actually use the library yet. Secretly hoping you'll will tell me about all the cons so I don't have to do the research myself. Currently choosing a library based on which has the best saga-like support)

[yayr]

mobx-state-tree (mst) is an addition to mobx. While mobx is a rather generic approach to manage state via composable observables and actions, mst is a strongly opinionated enhancement of it that brings in e.g. strong typing and some simplifications. While mst was great for some simple things, it soon runs into issues at complex requirements, one of them being performance. In my scenarios after running into some of these issues, I then rebuilt everything in mobx and brought in the strong typing etc. via TypeScript and code governance. This worked great so far, not much boilerplate, great state/action componentisation, also a great serialization/deserialization out of the box with serializr.

[SilverSlash]

Hi, I've not actually used redux at any scale but I have used react a lot (sounds silly?).

I was wondering, would it be possible to have something like a strict subset of redux with minimal boilerplate and very few and very simple API functions which are redux compatible. But which can eventually be swapped with the full Redux library if need be?

[acemarke]

No, not really. Redux itself _is_ already small - if you strip out the safety checks, it's less than 100 lines [0], and you can see the core concept in less than 25 [1].

Part of the issue is that people use the word "boilerplate" to refer to many different things, such as writing action creator functions, writing immutable update logic, calling `connect()` to generate wrapper components that talk to the Redux store, etc. Everyone seems to have a different thing that they are concerned about.

The "starter kit" package I linked tries to address several of the most common concerns, while still keeping Redux the way it's meant to be used.

[0] https://gist.github.com/gaearon/ffd88b0e4f00b22c3159

[1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[xab9]

Thank you! I've been thinking of writing a cli helper to generate the boilerplate, but that would be specific to the project I'm working on.

I really loved working with angular-cli, where you can create most of the skeletons with the cli tool (which in turn is supported by webstorm).

[Yuioup]

I know this is going to sound like blasphemy, but is the TS version also going to support Angular?

[acemarke]

You can already use Redux with any UI layer or framework, whether it be React, Angular, Vue, jQuery, or vanilla JS.

The starter kit package just provides some additional utilities for common use cases. You could use it in a TS app already, you'd just have to stub out the type declarations yourself. Reworking the package to be written in TS is mostly to allow easier integration with users building their apps in TS.

[xab9]

isn't ngrx the popular store implementation for angular projects?

[blackn1ght]

Pretty much. I'm using ngxs in my ng6 project at work and it'a fantasic library. Way less boilerplate than Redux w/TS.

[morganics]

This is why we are using MobX at work. The amount of boilerplate code in Redux is insane.

[xab9]

I would just love to work with mobx, coming from vue, the project is already big enough and a rewrite is not an option in this stage. Are people using redux and mobx together?

[ryan-allen]

I'm a fan of mobx, using Typescript also.

[flyingswift]

You could try the https://github.com/Hotell/rex-tils package. I find these action creator utilities make typing the redux concepts a little easier.

Also, I am working on a library which aims to centralize all of the redux constructs into reusable modules. It doesn't eliminate all if the boilerplate, but I think it makes it easier to add things to the store. https://redux-dynamic-modules.js.org

[scns]

Check out ReasonML with reason-react. Immutability, reducers and type inference built in. Way less code to write and strong guarantees by the compiler.

[fastball]

I've really enjoyed using rematch[0] on top of redux to reduce boilerplate.

0: https://rematch.gitbooks.io/rematch/

[fouc]

State management can be simplified using streams & the meiosis pattern. No real need for redux/mobx/etc

[xab9]

That' true. But wherever I look, projects and people bought into this idea that if it's good enough for Facebook (or Google in the case of Angular) then going with react+redux is a future-proof idea.