I have a library which builds on top of O.o [1]. I dig immutability but immutable.js is far from perfect, especially when used from within a strongly typed language:
first.setIn(["foo","val"], 500)
The type checker can not verify that `first.foo.bar` exists and is of type Number!
Avers plays nicely with TypeScript (it's actually written in TS). If I add proper property type annotations to the objects, TypeScript will warn me when I try to access or modify a property which doesn't exist.
It is true that O.o libraries modify the objects in-place. But that's only an issue if you consider those objects the ground source of truth. But there is a different way to look at it: Treat O.o just as a way to observe changes, but then apply them to immutable stores. Something which I may add support for in the future (see [2], "Immutable applyOperation").
Another way to look at it is: When you render the UI with React, you have to pass React the data (stores, objects) as well as a specification how it is allowed to modify the data. Avers sort of combines the two so you only have to pass around one reference which includes both. How you handle the changes (whether by mutating the objects in-place or applying them to immutable stores) is up to you.
As an aside around dealing with properties that don't exist yet, I have found the following pattern very useful. It greatly reduces the number of checks I have to do in an if statement and has made my code more maintainable by reducing the amount of boilerplate code I need to write inside of functions.
I recently read the re-frame ~manifesto~README[1] which is a compelling write up about that concept. Could you share some others initiatives in this vein?
9 comments
[ 3.1 ms ] story [ 31.1 ms ] threadSee https://youtu.be/I7IdS-PbEgI, and more specifically https://youtu.be/I7IdS-PbEgI?t=21m29s
Avers plays nicely with TypeScript (it's actually written in TS). If I add proper property type annotations to the objects, TypeScript will warn me when I try to access or modify a property which doesn't exist.
It is true that O.o libraries modify the objects in-place. But that's only an issue if you consider those objects the ground source of truth. But there is a different way to look at it: Treat O.o just as a way to observe changes, but then apply them to immutable stores. Something which I may add support for in the future (see [2], "Immutable applyOperation").
Another way to look at it is: When you render the UI with React, you have to pass React the data (stores, objects) as well as a specification how it is allowed to modify the data. Avers sort of combines the two so you only have to pass around one reference which includes both. How you handle the changes (whether by mutating the objects in-place or applying them to immutable stores) is up to you.
[1]: https://github.com/wereHamster/avers [2]: https://caurea.org/2015/02/08/the-future-of-avers.html
http://adripofjavascript.com/blog/drips/making-deep-property...
[1]https://github.com/Day8/re-frame
:D