Join discussion on Redux encapsulation?

[markerikson]

Hi. Generally not a fan of the "create a new Redux API without boilerplate by wrapping it in OOP" genre, but this one looks kinda different. The composability and use of connectAdvanced look particularly interesting.

The main venue for discussion of the "encapsulation" / "reusability" concept is over at https://github.com/slorber/scalable-frontend-with-elm-or-redux . You might want to go demonstrate your approach.

I suspect that @mattiamanzati and @jimbolla might be interested in glancing at this, for different reasons.

[jimbolla]

Cool. I haven't absorbed all the details, but generally speaking, this is what I hoped to accomplish by exposing connectAdvanced. I'm excited to see what mutations of Redux spawn forth. Why should React Router get all the good Javascript Fatigue? 😁

[markerikson]

As a related note, the "Variations" page of my Redux addons catalog is where I've listed all the "Redux wrappers" I've seen. And there's a bunch of them.

[esamattis]

Hi. Generally not a fan of the "create a new Redux API without boilerplate by wrapping it in OOP" genre, but this one looks kinda different.

Maybe because there's nothing OOP in it ;)

You might want to go demonstrate your approach.

Gladly. The RandomGif example should be easy to create. I'll implement it and post it. The actions of course won't be anything like in the "specification" because Lean Redux has only one action type :)

As a related note, the "Variations" page of my Redux addons catalog is where I've listed all the "Redux wrappers" I've seen. And there's a bunch of them.

Holy cow there's a lot. I hope I haven't accidentally created of a clone of an existing library.

[markerikson]

Maybe because there's nothing OOP in it ;)

Eh, yeah. That said, it does echo a lot of the OOP-type wrappers in that it "removes" the specific definition and handling of actions. Also not seeing a way to leverage the "encapsulation" aspect strictly on the reducer side, as this appears to be all in the React connection side of things.

Holy cow there's a lot. I hope I haven't accidentally created of a clone of an existing library.

Like I said, there's been a bunch of things along the same general line :) But, this one does seem to have some unique points to it.

[esamattis]

I've implemented the gif examples here https://epeli.github.io/lean-redux/examples/ (at the bottom).

Also not seeing a way to leverage the "encapsulation" aspect strictly on the reducer side, as this appears to be all in the React connection side of things.

Well the idea is after all that you don't have to write reducers at all :)

This library comes from the frustration of writing bunch of really small to medium sized apps with vanilla Redux. Because when writing number of smaller apps you cannot spend time building you application specific "libary" to make things easy to write. But I'm hoping that this approach would work for bigger apps too because of the clever scoping mechanism. Feedback is very welcome.

[markerikson]

Well the idea is after all that you don't have to write reducers at all :)

Right, and that's kinda my main point. It's a very interesting-looking experiment, and the demos you're showing off certainly prove that you've built something potentially useful. My concern, as with most of the other wrappers I've seen, is that they take things too far away from the core Redux ecosystem, and limit their usefulness.

I wrote a post a few months back in reply to the author of another one of these types of libraries, Radical, describing issues I see with this type of thing: https://news.ycombinator.com/item?id=11833301 .

Just to clarify: I'm not saying that your library is a bad idea, that it's not useful, or that you should stop working on it in any way. On the contrary, it's pretty interesting. It's just that it looks like another example of an existing trend where wrappers trying to "simplify" Redux basically wind up writing a wall between themselves and the rest of the ecosystem.

[esamattis]

Just to clarify: I'm not saying that your library is a bad idea, that it's not useful, or that you should stop working on it in any way.

No worries! I didn't think you were saying that :) Good discussions here.

My concern, as with most of the other wrappers I've seen, is that they take things too far away from the core Redux ecosystem, and limit their usefulness.

I do share this concern. One use case could be to use Lean Redux only as a local setState() replacement and for the global state one can keep using standard Redux actions and reducers.

[esamattis]

One use case could be to use Lean Redux only as a local setState() replacement and for the global state one can keep using standard Redux actions and reducers.

Actually I might just pivot to this direction even more.

The API would look like this

import {connectLean} from "lean-redux";

var Counter = ({count, inc}) => (
    <div>
        {count} <button onClick={inc}>inc</button>
    </div>
);
Counter = connectLean({
    getInitialState() {
        return {count: 0};
    },
    handlers: {
        inc() {
            this.setState({count: i + this.state.count});
        },
    },
})(Counter);

// Scope it to a myCounter key in the Redux state
// <Counter scope="myCounter" />

API like this would make it super simple to move local state to Redux state. Thoughts?

I would also get rid of the LeanUpdate/updeep concept and the thunk implementation. Async could be done just by accessing this.setState() from callbacks:

    handlers: {
        asyncInc() {
            setTimeout(() =>{
                this.setState({count: i + this.state.count});
            }, 100);
        },
    },

[markerikson]

Definitely a possibility. FYI, there are also a number of existing "local component state in Redux" libs, which I've got listed at https://github.com/markerikson/redux-ecosystem-links/blob/master/component-state.md . Again, haven't tried any of them myself, but might be a useful point of comparison.

[esamattis]

Did it and quite happy with it. Released as 2.0.0.

README got a lot smaller and I think learning curve goes to almost zero if users are familiar with vanilla React. state APIs.