Clojurians Log v2
matrix
Oh, I saw your #hoplon question. Glad to see you are still looking at transparent solutions, @chromalchemy.
Re #matrix and optimization, I am afraid I am no CLJS expert. I /did/ play with advance optimizations early on and remember mixed results. Indeed, the whole CLJS build landscape is rather off-putting. I think I started with David Nolen's meis project. https://github.com/swannodette/mies. [edit: Now I am using shadow-cljs}
My current roadmap is to get the trainer https://github.com/kennytilton/mxweb-trainer to a reasonable point and see if there is any interest, then worry about production release issues.
I just tried a release build and got some warnings, one on tufte and two on my XHR sub-project.
Sorry I cannot be of more help.
btw, @chromalchemy, if you happen to be all over these build issues I will be happy to drop what I am doing with the trainer for a day or three to work with you to see how #matrix optimizes.
I’m currently trying to push a feature without any cljs libs. And when I do a release build the js cant find the cljs function it’s trying to acll. It worked with a minimal cljs file… > CLJS build landscape is rather off-putting I must agree 😣 I have already sunk way more time this ui state management code than I expected.. If I can just get it to compile, I’ll probably be ok for now. But moving forward I definitely want a more reactive lib supporting this stuff. I really appreciate the attention. But if I’m not in a position to use it yet, I don’t want to hijack your flow.
Ps the fix was simple enough. Had to add ‘^ :export” type hints for public fns. (I avoid this kind of arcana tho)
Now the cljs is fine, but I still I have to wrangle with webpack, failing to bundle properly. And maybe update the thing?… which means maybe updating the whole codebase…? Not fun in js build grey zone 🤢
This stood out, of course: "Even for some relatively simple widgets, it is mind-numbingly complex! 😬" One of the problems with TodoMVC is that, while it has lots of things that /depend on/ the state, that state itself is trivially simple. It is like a one-hop flow repeated many places. As you discovered, the complexity grows exponentially with realistic program size, because unlike with the artificial exercise TodoMVC, real DAGs naturally have greater depth and interdependency. Good luck with the project!
Thanks for the support, and reminder that there (still) is a better way out of this tarpit. I contentiously abstained the whole jquery era of front end. This project is reminding me why. Lots of code, arbitrary separation (mvc anyone?), and hard work mapping and gluing it all together; for a generic non-reusable and still buggy component. In my old Hoplon todo app I was building way more complex interfaces, with lots of buttons and conditional displays, with a quarter the experience i have now. I probably under-appreciated what i was able to do there.
Haha, I did the same thing when first asked to do a Todo app as an exercise. I did not know about the official TodoMVC and ended up shooting for a richer U/X. Within four hours I understood that React sucked. It might have been two hours. 🙂