Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Om Next Quick Start

github.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Om Next Quick Start

#11

Post by jraines »

amelius wrote: post #10
Skinney wrote: post #6

Earlier quoted context omitted.

Don't understand the question. Om.Next allows you to have a single root component, that component is responsible for building a query for every sub-component. So you really only have a single query, then render based on the results of that query. Whenever data that is touched by the query changes, affected components are re-rendered. I would also assume that the time it takes to render the view is much greater than t…

Ok, perhaps I should rephrase the question. Let's assume there are X items in your component (say a simple list box), and there are Y users, each editing one or more items in that same component. At what values of X and Y will Om break down? Why I ask this is that before I get hooked on Om, I want to be sure that I'm not in a dead-end alley :) I want my application to be able to scale as necessary.

Hard to answer that with concrete numbers but Om Next handles optimistic and non-optimistic updates quite elegantly. Roughly speaking: each query expression is parsed twice, once locally and once in remote mode, and as long as your backend can handle Om Next query expressions, it Just Works:

Reading: https://github.com/swannodette/om-next-demo/blob/master/todo...

Mutating: https://github.com/swannodette/om-next-demo/blob/master/todo...

Re: Om Next Quick Start

#13

Post by swannodette »

Lots of new stuff in Om Next. Unlike Relay and Falcor we have recovered HTTP caching https://github.com/omcljs/om/wiki/Remote-Synchronization-Tut.... And due to the redesign Om Next now has a really fantastically simple automated testing story https://github.com/omcljs/om/wiki/Applying-Property-Based-Te...

Happy to take any questions.

Re: Om Next Quick Start

#14

Post by ams6110 »

hawkice wrote: post #4

I use Reagent (another Clojurescript React library), and it seems this might widen the gap between the two in terms of ease-of-getting-started. Reagent is dead simple to get going with, and requires you learn basically nothing to build even moderately complicated things. Om is... somewhat notorious for having more complex abstractions built around deep thought about maintaining e.g. a single point of mutable data. Th…

Link for the curious: https://holmsand.github.io/reagent/

Re: Om Next Quick Start

#15

Post by jarpineh »

swannodette wrote: post #13

Lots of new stuff in Om Next. Unlike Relay and Falcor we have recovered HTTP caching https://github.com/omcljs/om/wiki/Remote-Synchronization-Tut... . And due to the redesign Om Next now has a really fantastically simple automated testing story https://github.com/omcljs/om/wiki/Applying-Property-Based-Te... Happy to take any questions.

Could you clarify a bit the state of JS on ClojureScript land?

I just spend a weekend watching videos about Om Next and Devcards. I got Om Next inside Devcards working, but the journey from there to getting my JS based React components there was less than smooth.

I believe that things like GraphQL, Relay and Redux could provide what I have been missing on my web development story, namely code working with the data regardless of client/server separation. Om Next looks to give these things with a better language.

I'm now starting to build things with Om Next, since playing with Cljs on Devcards was really fun. I just had to rage quit a couple times trying to use my existing stuff.

I saw support for directly importing JS modules mentioned, but I could not find docs on how it could be used. Other option was to modify build configuration to get my JS files inserted into package space or converting them (I assume) to Clojure packages with CLJSJS. Finally I just mangled several build configs together which somehow worked.

I realize trying to keep one feet on JS land and other on Cljs side might not be high in your priorities, but my use case happens to require this. I keep trying, though, so thank you very much for what you've done.

Re: Om Next Quick Start

#16

Post by Skinney »

jarpineh wrote: post #15
swannodette wrote: post #13

Lots of new stuff in Om Next. Unlike Relay and Falcor we have recovered HTTP caching https://github.com/omcljs/om/wiki/Remote-Synchronization-Tut... . And due to the redesign Om Next now has a really fantastically simple automated testing story https://github.com/omcljs/om/wiki/Applying-Property-Based-Te... Happy to take any questions.

Could you clarify a bit the state of JS on ClojureScript land? I just spend a weekend watching videos about Om Next and Devcards. I got Om Next inside Devcards working, but the journey from there to getting my JS based React components there was less than smooth. I believe that things like GraphQL, Relay and Redux could provide what I have been missing on my web development story, namely code working with the data re…

Importing amd.js/umd/es6 modules would be preferred, but you could also include your .js files using the preamble option.

Re: Om Next Quick Start

#17

Post by swannodette »

jarpineh wrote: post #15
swannodette wrote: post #13

Lots of new stuff in Om Next. Unlike Relay and Falcor we have recovered HTTP caching https://github.com/omcljs/om/wiki/Remote-Synchronization-Tut... . And due to the redesign Om Next now has a really fantastically simple automated testing story https://github.com/omcljs/om/wiki/Applying-Property-Based-Te... Happy to take any questions.

Could you clarify a bit the state of JS on ClojureScript land? I just spend a weekend watching videos about Om Next and Devcards. I got Om Next inside Devcards working, but the journey from there to getting my JS based React components there was less than smooth. I believe that things like GraphQL, Relay and Redux could provide what I have been missing on my web development story, namely code working with the data re…

Using the most popular JavaScript libraries is absolutely not a problem. However integrating random React components in a ClojureScript build is a work in progress (you could also just pre-build your React bits first and avoid this issue entirely). Maria Geller and others in the community have pushed the CommonJS integration forward an incredible distance, we're at the point now where the devil is in the details. I suspect in 6 months or so using a random React component in the ClojureScript build process will not be so challenging.

Re: Om Next Quick Start

#18

Post by Skinney »

amelius wrote: post #10
Skinney wrote: post #6

Earlier quoted context omitted.

Don't understand the question. Om.Next allows you to have a single root component, that component is responsible for building a query for every sub-component. So you really only have a single query, then render based on the results of that query. Whenever data that is touched by the query changes, affected components are re-rendered. I would also assume that the time it takes to render the view is much greater than t…

Ok, perhaps I should rephrase the question. Let's assume there are X items in your component (say a simple list box), and there are Y users, each editing one or more items in that same component. At what values of X and Y will Om break down? Why I ask this is that before I get hooked on Om, I want to be sure that I'm not in a dead-end alley :) I want my application to be able to scale as necessary.

Depends entirely on your queries/mutations and app requirements. Om does produce regular React components, and due to immutable by default collections and data, Om can even beat React when it comes to rendering performance. At the very least, you should expect React-like performance. Then again, I've written a couple of frontend applications, and React/Reagent/Om has never been a problem for me from a performance standpoint. If it was, ClojureScript makes it easy to write code that uses regular js-objects and arrays, so it's always possible to optimize with "low-level" code when necessary. Like I said though, it has never been necessary.

Re: Om Next Quick Start

#19

Post by jarpineh »

swannodette wrote: post #17
jarpineh wrote: post #15

Earlier quoted context omitted.

Could you clarify a bit the state of JS on ClojureScript land? I just spend a weekend watching videos about Om Next and Devcards. I got Om Next inside Devcards working, but the journey from there to getting my JS based React components there was less than smooth. I believe that things like GraphQL, Relay and Redux could provide what I have been missing on my web development story, namely code working with the data re…

Using the most popular JavaScript libraries is absolutely not a problem. However integrating random React components in a ClojureScript build is a work in progress (you could also just pre-build your React bits first and avoid this issue entirely). Maria Geller and others in the community have pushed the CommonJS integration forward an incredible distance, we're at the point now where the devil is in the details. I s…

Ok, thank you.

I have to see how to go about making JS with Webpack -> Cljs a bit more automated.

Re: Om Next Quick Start

#20

Post by jarpineh »

Skinney wrote: post #16
jarpineh wrote: post #15

Earlier quoted context omitted.

Could you clarify a bit the state of JS on ClojureScript land? I just spend a weekend watching videos about Om Next and Devcards. I got Om Next inside Devcards working, but the journey from there to getting my JS based React components there was less than smooth. I believe that things like GraphQL, Relay and Redux could provide what I have been missing on my web development story, namely code working with the data re…

Importing amd.js/umd/es6 modules would be preferred, but you could also include your .js files using the preamble option.

I think I used foreign-libs at the end. I might have had preamble there at one point, but that iteration did not work. Using Figwheel + Devcards build in Leininged seems to swallow compile information, or at least I couldn't see any error messages unless I broke the build very badly...
Post reply on HN