genius

Haha. I’ll take the compliment.

>Presumably by then we’ll have our mandatory NeuraLinks and the YouTube algorithm will be able to inject real-time ML generated content (and ads) straight into our brains

exactly what happens on a black mirror episode. Recommended!

There's nothing new under the sun, I thought I was being clever.

I'll have to watch it!

sweeeet

The only issue I thought about would be when using json as I guess this would lose the namespace infos. Did you have issue with that ?

Here's some valid json that might be useful:

    {"signup/username": "John",
     "signup/password": "pg4pres"}

Then, because you can pass in a function to get called on the keys, just check for a regex like (.+)/(.+) and turn it into a keyword. Here I'll write a function like that real quick using a repl with a nice ux: https://s3-us-east-2.amazonaws.com/photoblobs/Screen_Recordi...

Sorta! Cheshire gives you a key-fn entry point. For small JSON objects you may just want the same namespace and then that is sufficient. Otherwise you can look up the right namespace in that fn or walk that tree (I’ve used specter for this) to correctly annotate.

I keep my data in a JSON database (RethinkDB). This is not a problem at all: namespaced keywords are converted to strings and the conversion is well-defined in both directions.

Great post, thanks ! What is "red" above "re-frame" ?

It's an extension to re-frame that we built. It addresses some of the (subjective) shortcomings of re-frame, mainly the over-reliance on keywords. We'll be open-sourcing it soon.

a bit higher and we can make a hackernews grid inception

Is there perf gain when comparing 2 immutable obj deeply with === ?

A `===` comparison is explicitly _not_ a deep comparison. It's a reference comparison, ie, "are these two variables pointing to the same object in memory?". Under the hood, that probably is interpreted as a simple pointer comparison, which is fast and cheap. That's why it's the preferred approach for doing comparisons in cases like this. _If_ you update your data immutably, then you get the benefit of quick and simple comparisons to see if things are different.

Now, a reference comparison only tells you if the objects themselves are different. It's entirely possible to have two different objects with the same or equivalent contents, such as in @kasbah's example. Both objects have a key named `a` that has a value of 1, but the objects are different references. The overall assumption when you update data immutably and compare like this is that _if_ two objects are different references, then they _probably_ have different contents, and it's time to re-render your UI.

It appears equality checks for objects is not supported i.e.:

    Immutable({a: 1}) !== Immutable({a: 1})

There is no built in equality function either [1] so that seems like that's a big advantage Immutable.js has over this. Maybe seamless-immutable-diff [2] could be a way to do it but I am not sure on the performance.

[1]: https://github.com/rtfeldman/seamless-immutable/issues/186 [2]: https://www.npmjs.com/package/seamless-immutable-diff

Not to use react or redux ? What alternative did he propose ?

Location: France Remote: Yes at first Willing to relocate: Yes, after remote trial Technologies: FP lang, Scala, Clojure, React, CLJS, Om Resume: twitter.com/jvuillermet https://github.com/ioRekz Email: jeremy.vuillermet@gmail.com

Nice one ! Had some issues to correctly save the background as well as the new drawings when uploading in my personal app