Clojurians Log v2
om
still learning om-next. Apart from the documentation that seems a bit neglected I think it’s brilliant. But hard to sell clojurescript and a framework/library that’s in alpha 😞
also it seems to a major deal-breaker for people that write tutorials, since it’s hard to invest the time to learn & make a online course if it’s in alpha.
@currentoor Do yo also have code splitting on your production app ?
@claudiu no, we haven’t had a need for that. The Closure compiler makes our build small enough.
@claudiu also have seen @tony.kay’s tutorial? https://github.com/untangled-web/untangled-devguide meant to be cloned but here’s a live version http://untangled-web.github.io/untangled/guide.html his untangled libraries make it much easier to get started with om next
@dnolen @anmonteiro is there anything mere mortals like me can do to help get Om Next out of alpha?
I’d love to see wider adoption and ecosystem of this amazing tech :cljs:
I’m happy to help write tests, documentation, tutorials, example projects, heck I’ll even do your dry cleaning 😉
@currentoor the only thing that’s blocking beta is technically error stuff, but to be honest no one has strongly complained so maybe it’s time to throw in the towel and do that in a next release?
That would be cool.
@claudiu I implemented code splitting last week. Can share if you're interested
@petterik Do you use compassus for routing in your code splitting project? I would like to see an example of this.
@r0man I do not use compassus because I use datascript (and they don't work together?). But the routing I use should be similar to compassus, so it's probably possible to adapt what I've done to compassus
@urbank It's been working well for us. Whenever we've had any performance issues we've been able to cache results and update the cache whenever there are new or removed datoms, almost like a datomic "since" api. Our current product is running well without any of these optimizations. It's hard to answer how much we've querying.
Thanks for the response! Could you tell me approximately the maximum number of components you have rendered at once? How many of them are querying the datascript database? Sorry for the interrogation! 😛
The number of queries has never been the bottleneck. It's the size of the data they return that's been the bottleneck because of om.next.impl.parser/path-meta which is run on the result of queries for indexing purposes. Datascript's pull api is usually fast enough, but sometimes it's worth it to go straight to the datascript.core/datoms api.
But to answer your question, we've got about 5-10 om.next component's with queries rendering at any time.
Somehow I missed your answer. Interesting. Not where I expected the bottleneck to be. Thanks for answering!
Reading my answer again, it's not accurate. It was based on how I used reads and datascript a long time ago. path-meta's performance has improved and I was using datoms api.
Comparing path-meta and pull in our app now, pull is about 6 times slower (with :optimizations :none).
Unfortunately I have to go now, and I might not be on tomorrow
(sorry for the cliffhanger)
@petterik Thanks, would still be interested to take a look. I'll ping you in some days, when I actually get to this point in my app.
@petterik yes please, really curious how om-next and code splitting go together.
petterik: Off topic, but I'm interested in your experiance with datascript + om. Have you run into any performance issues? How much are you querying?
To try to make sure there are no problems from my side I got rid of untangled-ui then did a git clone of it to get the latest. Also as part of this reset I did rm -rf node_modules && npm i. But I still get the same problem Error: Cannot find module 'postcss-Nested' when running gulp watch. This is from trying to run the three commands mentioned here: https://github.com/untangled-web/untangled-ui/blob/develop/README-css.md#development