Clojurians Log v2
hoplon
This is going down right now ⬆️
thanks to all who attended, exciting stuff! here's that demo i showed: https://tailrecursion.com/~alan/ttt/basic.html 🧵
and here's the channel for Ken's matrix project: #matrix
Thanks again for organizing this, Alan! I had fun
my pleasure Dave thanks for coming
Sorry i missed it guys. Travelling to the conj. Viva la Hoplon
Thank you Alan, it was great!
@dave sources and sinks here are the cell dependency graph edges; input cells have no sources https://github.com/hoplon/javelin/blob/master/src/javelin/core.cljs#L104. they are javascript arrays. in the past they were https://github.com/tailrecursion/cljs-priority-map ordered by https://github.com/hoplon/javelin/blob/master/src/javelin/core.cljs#L19 but now they are JS that we binary insert into, still sorted by rank
..from any cell you can walk the graph of any connected cells and learn possibly interesting things, or populate a graph like in the demo. using the JS debugger you can also find Cell instances even if they have disjoint graphs
That's interesting! I'll have to explore that the next time I'm sifting through our cell spaghetti 🙂
I will say, though, that most of the time, I'm able to figure out any Hoplon problem by sprinkling (cell= (prn :my-cell my-cell)) in the affected areas
at a minimum i'm wondering about a bookmarklet or chrome extension that would economize e.g. setting watches on cells
ah that takes me back, the unreasonable effectiveness of (cell= (prn...
I just thought of a common mistake that newcomers have made in our code base: not using the appropriate if-tpl or cell=, etc. when using a cell's value in an if statement. Something like this:
(p
(if some-cell
"truthy"
"falsy"))some-cell is a cell, and thus will always be truthy because it's a JS object. But the application appeared to work fine when they tested it because maybe they only tested the truthy path.
It gets more confusing when you start getting into writing functions that return cells, because then you have to understand that the function returns a cell, and that cell= doesn't know that by default, so you have to either use formulet / formula-of or invoke ~ black magic (I still have no idea how that works!)One way I saw in a reagent codebase is to make clear using naming conventions what is a cell or what returns a cell. Over there people used & as a suffix on ratoms (which would be the equivalent of cells in hoplon). Maybe you could also have something like &= for formula cells as those cannot be updated. Functions that returns cells/formula cells could also use the same naming convention.
It is sort of ugly but effective when the convention is followed. But in a large codebase that would be confusing for sometime until that information is reliable.
😂 . fwiw not much magic to ~, it's just a way to instruct the code walker not to wrap the succeeding form in the boilerplate that will dereference it
@hiskennyness i forgot to mention, and may be of interest to you, ECL (the CL impl.) is host to an increasingly viable wasm port
Good call!
"They might not realize that some-cell is a cell,..."
Do they get up to speed pretty quickly?
Following up on sth: maybe look at wrapping React instead of HTML? I find it only takes a few weeks to wrap sth new. Except Flutter. That was three months. Almost killed me. 🪦 But going from HTML to React was pretty painless. I kinda stopped when I saw React saying they had to see all state -- that would not have worked. And then ClojureDart was released, so I moved on.
I think that state visibility constraint of React is opt-in for now. Have not looked in a while.
could definitely be a thing... hoplon's mediation with HTML is done entirely through a handful of multimethods, e..g https://github.com/hoplon/hoplon/blob/master/src/hoplon/goog.cljs... perhaps these could be implemented for React.Component
Yep. To me, anything like Hoplon/Javelin can be cast as a "reactive first" solution: start with well-executed (transparent, granular) reactive, then the rest (talking to HTML or React or Flutter) is just a pluggable UI backend requiring a few weeks or at worst months of gluing, a finite effort. We could even flip the arrow and truly turn, say, ReactNative into a plug-in, but then I suspect we make it hard to get to specific RN capabilities. A plug-in approach would not make the connection that much easier, so I like the unfettered access to the wrappee.
I should add that React was a breeze because I could lose all the low-level DOM maintenance, which I see Hoplon does -- I just had to call setState. Same with Flutter, btw. Flutter killed me with its low-level OO I had to make happen.
It's hard to say whether or not people get up to speed quickly. I guess it probably varies from person to person. I'd like to think that it's easy to grasp, but I'm also biased because I learned Hoplon directly from its authors, in person, 8 years ago 😄
I worry about the bias a lot myself, having done it for 25 years and written the damn things. 🙂 But have you found that some people never miss a beat? I have near zero adoption, but the little I have is people who I did not know existed until they shared some work--they had just figured it out from some examples. That's my excuse for not documenting the thing, btw. 🙂
It seems like most people do OK, but I also find myself providing a fair amount of Hoplon guidance. It's hard to tell if that's because we've done confusing things in our code in particular, or if Hoplon could benefit from having some kind of best practices guide or cookbook. Maybe it's both 🤔
I think one thing missing in software today is libary authors finishing good work with more good work to make the d/x easy. I am looking at you, Linus. 🙂 But the reason I am so high on Hoplon/Javelin is the transparent d/x. Plus I would rather work on making the d/x slicker than write documentation. 🤣