Impressive but would love to see a real-world example

[mikecann]

This is really impressive stuff and something I have been looking for for a long time.

I know you have the bookshelf example in the spec but what would really aid understanding is something a little more realistic and covers some common use-cases.

Perhaps an example that includes an async operation such as pulling from reddit or something? Then show how you would do the connect to React components and mapping of props to state etc...

That would definately help with understanding how it all fits together.

As I say this is really good stuff, keep up the great work!

[danielearwicker]

Thanks!

I'm currently working on a sample React app, and using it to work out a nice way of binding components to cursors. I think I'm almost there.

I will definitely get into asynchronous operations next. Obviously using promises so async/await will fit in nicely (initially backending with Babel and then ripping it out when TS 2.1 arrives).

[mikecann]

Awesome! Yes definately async / await.

I write a lot of chrome extensions so I dont have to worry about ES5 compatibility issues which is nice.

Really looking forward to seeing what you come up with.

[basarat]

(initially backending with Babel and then ripping it out when TS 2.1 arrives).

TS nightly has just got async await support. Even when targetting ES5 :rose:

[danielearwicker]

There's now a separate example repo. Writing it up next...

Play with it here

Once it's written up I'll look at async.

[mikecann]

Looks good, looking forward to seeing some of your reasoning such as why the props is distinct from the shop: https://github.com/danielearwicker/immuto-example/blob/master/components/ShopEditor.tsx#L13

[danielearwicker]

That's a great question. I was tinkering with that this morning as I started trying to explain it, which is always a good indicator that it requires some tinkering!

Basically for performance you want to make a component have the intelligence to check whether data has changed before it bothers to render. To do this you implement shouldComponentRender. There was a mixin that did this but we don't have those in TS and ES2015. But the same thing would apply here because all data is immutable so we can just shallow compare the cursor.state and we know if anything has changed.

So I want to provide something you can wrap components in to implement shouldComponentRender, and I mixed that together with the business of mapping from a "parent" cursor to a "child" one. Having the cursor as a separate parameter from props helped with writing the binding functions.

But I shouldn't have mixed them together, as it has just made both of them harder to explain. (Ironically I haven't even got around to implementing shouldComponentRender yet anyway...)

It's going to be a lot more obvious what's going on if I separate them out. Watch this space...

[mikecann]

Thanks for explaining that! I will hang on until you are done with it, really looking forward to your result :smile:

[danielearwicker]

Walkthrough blog post is up and example source now has only ordinary react stateless components, which looks a lot less exotic. Thanks for the feedback.

[mikecann]

Awesome stuff mate! Just read through all of it, really good stuff, plus I learnt a new word "sobriquet" :+1:

I think I definately need to get in there and try it out on my own project to fully understand it.

I know its really early days with this but it might be good to also demonstrate that this is all easily unit-testable :smile:

Anyways keep it up, really impressed, learning a lot!

[danielearwicker]

Thanks, having a lot of fun with this. I should probably cover mixing it into an existing Redux project to allow gradual adoption. Immutable itself is just a way of building a reducer, which is just a pure function, so unit testing a reducer is very straightforward: call it with a state and an action and see what new state you get back.

Also stateless react components are pure functions, again very testable. In the simple tests for optimize in the immuto-react repo, I get React to actual render to jsdom and check that it only does so when the props really change.

All the user code in an app consists of reducers and React components, all pure functions.

Also for properties and collections (with automatic reducers), they are so declarative and simple I wonder if there's much value in testing them. It would be like writing a test for the ability to say obj.x = 5 and assert obj.x == 5.