Anyone run into issues where cljs advanced compilation seems to be stripping static methods like (query [_] ...
off of any om components?
@bnoguchi I've seen issues with advanced compilation messing with (implements? IQuery ...)
Awesome, glad I caught yours 🙂 It took me nearly 2 days to debug that
matthavener: Do you recall what adjustments fixed the issue?
if you require the om.next namespace in the JVM and then call the cljs compiler it causes the issue
if you're using lein cljsbuild or something you should be fine
That was it, thanks. I was trying to perform advanced compile with figwheel after repl loaded
uwo: I’ve made something using nothing but reagent then another app using re-frame/reagent and the latter was a lot easier to reason about. Everything works very well, the documentation on re-frame is extremely comprehensive and I’ve been able to mold my frontend to whatever I want and I’m extremely productive. The only thing that I’ve had annoyances with is dealing with complex relationships of normalized data, doing joins manually by filtering maps/vectors in subscriptions. I’m looking into re-posh now which seems to solve this.
@tony.kay I'm looking to choose between the two, are you implying there that om.next docs are in better shape than reagent?
@tony.kay I'm not sure I fully fathom what the role of https://github.com/awkay/untangled/blob/develop/GettingStarted.adoc is, what problem it solves in om.next which I should probably be aware (or beware) of. Or is it just a full getting-started for om.next?
Kind of awkward there's no lein new
bootstrap command for creating an empty om.next project .... or I've just not stumbled upon one.
Many thanks for any comments!
think it’s getting started for untangled, it’s built on top of om-next but it’s a bit different in some ways 🙂
@claudio mmm I see
It is always a bit unnerving to see a library solving something about a framework that is new itself 😉 makes you wonder about om.next
@matan kinda makes total sense in the case of om-next.
since it’s insanely flexible, there’s also a lot of room for you to improve and go in one direction or another
all ears
untangled keeps the state as a map (as in om-next default) while om-next allows you to keep it as datascript or any other storage.
it also has a parser for reads, so no logic in the readparser, all the loading data logic is done by mutations
a neat thing it seems to have is that you can define your initial state in the component, and the app-state can be generated.
you also get a lot of utility functions 🙂
moved to om-next from untangled so that I can understand things better, but now back with untangled since I was basically on the path to writing my own untangled :))
But then, this implies a very lengthy learning curve, om-next → untangled, just to reach some form of productivity, doesn't it?
Also doesn't it kind of imply some bad design choices were made in om.next itself?
om-next seems to be scheleton for doing your own framework on top of it by design. You get the benefit of a lot of flexibility.
think untangled with it’s awesome documentation makes it relatively easy to reach a form of productiveness.
I want server side rendering and code-splitting for my project.
Could not find any approach of doing this documented online, for om-next or untangled.
sounds like a problem
The untangled home page says: > We consider simplicity an objective measurement: Minimal complexity. Easy and hard are relative terms (e.g. German might be easy for you and hard for me). We derive this standpoint both from our collective experience and from Rich Hickey's wonderful expression of it in his talk Simple Made Easy. Hard is something you can address on a personal or team level through training and time. Complexity is, well, complex! Looking at problems from different angles can often reveal simplifications, but eventually you'll arrive at the simplest possible solution (yet found). To us, hard is about the ability to reason. It is about not knowing what happens because of out-of-order execution. It is about having to write and understand dependency injection for every artifact in a system. It's about work and thought that just gets in the way of solving your problem.
No idea what he's trying to say there, quite horribly written if I may say so.
to me it’s like: om-next & untangled … are harder to understand when getting started, you need to put in a bit more work until you get productive, but then you’re code is very easy to reason about.
Yeah I know, just horribly confusingly articulated there ..
Going back, sounds like you are stuck with that ― > Could not find any approach of doing this documented online, for om-next or untangled.
yep 😄 working on it now, and as soon as I figure it out will share. Most people seem to be doing frontend only apps.
Om-next works, and so does untangled. Just trying to find a nice approach to reuse the frontend logic on backend.
mmmmm
have you seen tony kay’s tutorial videos ?
not yet
@matan Thanks for the feedback. I agree the website is too wordy, but just have not gotten around to fixing it. Also, you could be a bit nicer in your criticism. Perhaps a positive suggestion. With regard to the GettingStarted guide: Om Next is a library of building block, which has been stated here on multiple occasions. It does take some time and effort to plug in all of the pieces that are needed. Untangled was started as a separate effort about the time Om Next came out. We decided to use Om Next as the underpinnings because it fit very well with the direction we were headed. Untangled makes many of the decisions you’d have to make when using Om Next, and the getting started guide is an example of what Om Next can look like once you’ve added those decisions on top of it.
which will be welcome
The lein template is not being maintained. Clone untangled-template instead. I have limited time, and maintaining a lein template bring no real benefits, but does require additional effort. I decided not to keep putting effort there until other more important things are done. Clone is just as easy.
With regard to evaluating what to use: There is absolutely no substitute for experience and actually getting your hands dirty. You can build anything with any of these things. Do some work. Write some code. List out the common things you struggle with in development, and how each of them will help you reduce complexity and address those issues.
tony.kay: agreed. apologies.
didn't realize the authors are here, so was speaking freely, but I didn't mean it to sound like that
@tony.kay rest assured you have my admiration for maintaining such a complicated library, it was not meant to sound like feedback, just a stupid developer ephemeral rant 😭
No worries…but better to rant in a PM 🙂
It isn’t all that complicated 😉 That’s the point 😄 It just has a lot of parts, all simple 😜
Right!
I take it upon myself that if I learn om.next
and then untangled
, I would PR to improve the website
Are there any examples with server parser doing async reads? I'm experimenting with some parser read responses to accept channels in the :value
response.. currently doing the manually a (go-loop to <! all before callback - not sure if someone else thought about this, perhaps Om could support readers or mutations returning {:channel } to do the async/<!