Om Next Quick Start
github.com
Om Next Quick Start
1–10 of 23 posts
Re: Om Next Quick Start
#2I was hoping that in om next boilerplate will be cleaned up, but seems like it's not really different from original om. No reify is nice though.
Re: Om Next Quick Start
#3What about performance? How many data queries can it handle per component, realistically? How many connections can it handle? I.e., where will this solution break down?
Are the transactions (issued from within the browser) performed optimistically? If so, will this not give "flicker" in the browser in case a transaction needs to be rolled back? Is it also possible to easily perform a transaction from the server (i.e., not optimistically)?
Re: Om Next Quick Start
#4I 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. This new stuff is... not something I think I could get right the first try.
That all being said, David Nolan is clearly a gamer -- Om will be interesting to watch even for people who aren't using it.
Re: Om Next Quick Start
#5I 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…
What I always worry about is not the ease-of-getting-started, but more the ease-of-scaling-modification-and-extending :)
Re: Om Next Quick Start
#6What about performance? How many data queries can it handle per component, realistically? How many connections can it handle? I.e., where will this solution break down? Are the transactions (issued from within the browser) performed optimistically? If so, will this not give "flicker" in the browser in case a transaction needs to be rolled back? Is it also possible to easily perform a transaction from the server (i.e.…
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 the time it takes to run a query, although that depends on your app/query.
Re: Om Next Quick Start
#7I 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…
If you use re-frame with reagent (and you should) then the ideas aren't that difficult to grasp. Om.next is more oppinionated regarding where you're allowed to run queries (subscriptions in re-frame) and transactions (handlers in re-frame), and forces you to build a single large query from the root component (wheras re-frame allows you to run several queries from every component).
Re: Om Next Quick Start
#8I 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…
What I always worry about is not the ease-of-getting-started, but more the ease-of-scaling-modification-and-extending :)
The jury remains out on that one too. Om is a bit marmite. :)
Re: Om Next Quick Start
#9I 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…
Reagent is very nice and by itself very easy to get started with.
That said, I think Om Next is more comparable to Re-frame (https://github.com/Day8/re-frame) as far as being more opinionated about handling data flow.
In that comparison, I don't think it involves any more complex abstractions or deep thought. In both cases, there is some of that, but both cases are also shining examples of explanatory documentation, which to me were edifying to read because they turn those abstractions into concrete implementations, with examples, and explain the deep thought in a clear manner.
Re: Om Next Quick Start
#10What about performance? How many data queries can it handle per component, realistically? How many connections can it handle? I.e., where will this solution break down? Are the transactions (issued from within the browser) performed optimistically? If so, will this not give "flicker" in the browser in case a transaction needs to be rolled back? Is it also possible to easily perform a transaction from the server (i.e.…
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.