@adamfrey your simple question had way bigger ramifications than I originally considered

in a good way!

great!

Hello guys, hello @dnolen , so I took time to clean up a bit, https://gist.github.com/leontalbot/1d57bb05c063a989757c

when I toggle first question radio button I get :

[ 11.488s] [om.next] #object[votepourca.omnexttest.Answer] transacted '[(selections/update-radio {:value value, :name name})], #uuid "35d87a1d-a354-4dc3-9bea-967ab9c6e470"
next.cljs?rel=1446568734541:905

Uncaught #error {:message "No queries exist for component path (votepourca.omnexttest/Form votepourca.omnexttest/Question votepourca.omnexttest/Answer)", :data {:type :om.next/no-queries}}

And the mutation doesn't do anything.

Anyone? probably a newbie mistake but can't find it!

Thanks in advance!!

(Note: when I click a second time on any radio button, I don't get the error message, only the transacted trace, but again nothing changes.)

I updated the example

by adding a subquery :a -> {:a ~subquery} for answers in Question UI I don't get the error message

(defui Question
  static om/Ident
  (ident [this {:keys [id]}]
         [:questions/by-id id])

  static om/IQuery
  (query [this]
         (let [subquery (om/get-query Answer)]
           `[:id :type :label {:a ~subquery}]))

But the mutation doesn't work, and I loose my radio button props such as type or name so that I when I toggle a radio button, it changes in regular text input...

i’m trying to build a simple example that uses om/subquery to fetch data for the currently displayed view. this seems very similar to @bplatz’s question about an idiomatic way to build up queries for only rendered components. Basically on demand fetching for only what’s visible. the example linked to below has a mutation that modifies :route then renders a different component. at this point the repl shows the Roots query has been updated but it doesn’t re-render. i admit it seems dumb to have some state change, render, then render again because your query has changed because you mounted a child ref’ed by a subquery. however, directly changing the query directly isn’t a good option because i want an unrelated component to be able to update :route via a mutation and cause this component to render a different view. interesting pieces from example here: https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs#L116 https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs#L136-L141

What's the right command to build om-next-demo?

I have an app which can be viewed in multiple languages (English/Chinese). So I store the current language in the Root view - in local state (initLocalState?). Or should that be shared? How do I ripple the selected language down to the child views? In props, query params, shared? Help! Thanks!

@leontalbot: I reported the same in an earlier comment. I think there might still be an issue with components 3+ levels deep but a simple solution is not to transact from the Answer component. Instead make a callback to a computed fn from Question. This should fix it.

take a look at my description from earlier this week for more details since there I used a slightly different fix

@simonb: sorry don’t have time to explain how to get om-next-demo running. Sounds like you want to look at :shared which I fixed up yesterday. Not in a release yet though. You will need to install from master.

@jdubie: example is too long for me look at sorry

if people actually want me to look at stuff minimize it to the actual problem

most problems can be described with about as much code as I use in my tutorials

which is nothing at all

@leontalbot: your example is also still too cluttered for me to consider

Hello ! Is it me or there is a problem in the last Om-Next cut with the :shared and :shared-fn options ? There are optional but it fails at the expression :

(when (contains? config :shared-fn)
                                                 ((:shared-fn config) data)))

@hmadelaine: hrm what’s the bug there?

@dnolen Cannot read property 'call' of null

(contains? config :shared-fn) returns true

@hmadelaine: oops right

fixing

@dnolen thanks. I'm reading the source. I think I have to use :shared-fn so can I change to reflect (say) a change of language. I think, :shared-fn gets passed props - props are immutable (right?). So, I'm just wondering how to get the change into :shared and how to propagate the change down to the children. Is this right or can I just use :shared (not use :shared-fn) and change the language key in :shared. Thanks!

@hmadelaine: fixed!

@dnolen: thanks !

@simonb props are immutable values but that doesn’t mean they don’t change over time

:shared-fn will run again if you change something at the root.

@dnolen can a component modify its own props? For example, the root component is inited with props indicating a language of English. Then the user selects Chinese, how should I get this change into the root so it ripples down to the children? Thanks.

@simonb: om.next/transact! is what you're looking for

@simonb: The root component gets its props via its own query. So you could have it query for [:app/lang ...]. The implement a read method for :app/lang and a mutate method for 'app/set-lang that changes :app/lang in the app state. Then, use :shared-fn (fn [props] {:lang (:app/lang props)}). When you want to change the language in your app (e.g. by clicking on a button), kick off a transaction like this: (om/transact! '[(app/set-lang {:lang "en"}) :app/lang]) (with ' = backtick).

@jannis thanks that's a big help. Is :changed-fn above :shared-fn ?

Oh, yes

So, props == query. Is this the same for all components? Does query always get added to props?

@simonb Yes, if you implement it correctly it is. :shared and om/computed are ways to pass information outside of query if necessary.

But beyond the root component, you are responsible for passing the proper props down to each component according to their query contract. There isn't magic in there that will do that for you.

@simonb: props = query result (your responsibility to pass down the results from the parent) + computed (for e.g. callbacks, stuff that is not part of the query)

@jdubie I've been thinking about the best way to do this. I think ideally the router should handle modification of the query, and you sort of need the selection to happen outside of IQuery, as you want the query modified prior to it being passed to the parser. One idea is to use a key identifier for the route node components (similar to naming a interceptor in Pedestal, for example). If the query join in IQuery utilizes the same key, you could dynamically select the parts of the query that are relevant to the current route.

But it is a problem I feel is necessary to solve, at least for my app, and so far the methods to do so feel hacky and confusing... so I'm still working on figuring out the best way.

The method I'm describing would require a route component for each node in a nested route. You'd want the query joins to be exclusive of each other, and no other parts to the query except the mutually exclusive subcomponents.

@bplatz: this sounds overly complicated to me

if the queries are dramatically different and need coordination why even bother changing queries over just changing components

in general it’s better to talk about problems so that they can be understood

over whatever solution you’re mulling about Om Next and your interpretation of the solution

it just makes too hard to understand if there’s something missing or whether it’s another documentation issue

In the simplest of terms I can produce, the need is a nested data-driven router that only selects the bits of query that are relevant for the current route.

@bplatz & @jannis thanks. So, env in the read method of the parser is props? Or includes props? I'm trying to understand the query contract's relation to props on components. query returns a datalog expression, which gets passed to read, read also can access props for the component. Is that right? Thanks.

@bplatz: right but I don’t understand why you need this - what problem is this solving?

@simonb No, it is map that has the things you pass into it allowing you to get the props you need, based on the IQuery you declare.

(this is an honest question btw, just trying to understand what actual advantage you are trying to achieve)

@dnolen I come from the enterprise software space, so our apps have everything from analytics, workflow management, financials, etc. I simply want to ensure the entire app isn't loaded. The root component query, without further manipulation, contains everything the app could ever do.

Some data sets are large, and if not needed I want to ensure they are not loaded.

right so this is far into the category of things that Om Next does not care about and will never care about

this is about a problem that you’ve constructed

nothing fundamental

that said ...

I would not try to get this done with just the primitives

why not provide you own root class thing over defui that automates all the bits you will need

this is a problem I actually care about - are the Om primitives composable enough to accomplish higher level framework goals / abstractions

@bplatz: another possibility is that you just want a delay primitive

so you can just specify total queries and then force some part of the query to load

@bplatz: I think (from reading the om source) it includes [:state :shared :parser :logger]

@dnolen: my own root class is what I proposed above as a router, it would manipulate query from the outside.

A delay I think would be a nice addition, however for this particular case it may not be enough. Just the query graph itself could be significant, and it seems streamlining that to the relevant bits would provide more efficiency. But I don't really know yet, as none of this has been tried.

@simonb: Yes, and :state will contain your data, which you provide. I think a read through the wiki overviews is the best way to provide you context for this. I'd tackle that before reviewing source.

@bplatz: sorry for not being clear

I don’t mean root class as in the root of component tree

I mean root class as in new component type

a component type that knows how to be coordinated by the root

in the way that you are suggesting

hello

@dnolen: I have two questions for you. 1. No ideas how to use mixins let React with om. next, whether such a question? 2. Use of third-party components React?

@a.espolov: not interested in mixins

whatever people use those for, figure it out another way, protocols, specify etc.

3rd party components should work fine

@dnolen I think think more dynamism in IQuery would be ideal. Perhaps if you could also return a function with just :shared passed in, then you'd be able to put your route information into :shared and return just the parts of the query necessary. You shot down the idea, and probably for some reasons that are not clear to me, but in the interest of describing what could be a simple solution to me, that is it.

@bplatz: right because you offered a solution to a problem I don’t understand

in general not going to spend much time on feature ideas if I cannot understand the problem

thx

but I’m happy to work out what the real underlying problem is and come up with general solutions that cover a wider set of use cases

@bplatz: I also do not even understand what you’ve suggested about :shared

but as long as thing keep getting framed in terms of solutions I suspect I will continue to have conceptual difficulties where I would like to be of some help.

OK, that is a reasonable stance. I think the problem has been beat down enough and is understood, but please correct me if I'm wrong. I'm thinking in solutions now because I need to come up with one. If I think of any more parts to the problem or other use cases I'll send them your way.

@bplatz: no I still don’t understand the problem at all

because I’m struggling to find the underlying issue filtered through your current understanding of Om Next and the various straws you are grabbing at (which is fully to be expected)

I also haven’t seen any code at this point

it seems you could write at most 30 lines of code to demonstrate the issue

OK, I may just lack a better way of explaining it then. It is the ability to restrict the query graph to the parts that are relevant to the current UI state (or route). Same problem that Google Closure Modules solves for the relevant parts of your JavaScript code, which I've seen you produce great commentary about.

so it just sounds like you want the root to be in control the query

then why bother distributing it to components at all

that seems to me root of all of your problems

[{route-a-component (om/get-query RouteA)} {route-b-component (om/get-query RouteB)} {route-c-component (om/get-query RouteB)}]

Only pick up one of the three.

why bother with this?

if this creates problems for how you want to build your app?

absolutely nothing about Om Next says you have to build your query in this way - the docs just show the expected primary useage.

as in why can’t the root have it’s own query building mechanism?

it’s just data for whopping good reason

there’s no syntax restricting you

I want to distribute it to the components for the same value proposition you state for Om.Next. There is a lot of ease and power in the (om/get-query RouteA), which by itself is a nested query graph. The only thing is I just need one of RouteA, RouteB, or RouteC at a given time.

@bplatz: you’re still missing what I’m saying

you can put queries on the components

but how you build the master query

nothing prevent you from building the total query at the root for the whole thing

and have the root component supply a filtering thing

which walks the total query removing all the stuff that doesn’t matter

Which is exactly what I suggested I was doing in response to @jdubie and you then stated I was over complicating things and henceforth this conversation.

@bplatz: reading what you wrote that’s not the idea that I read

but it’s easy to misunderstand

I think if there is not a more native support of this sort of thing directly in Om.Next, then a router would take the responsibility of filtering the query, as it should know the route.

By aligning routes with query components, i.e. /index.html = :route-component-b, then you could use those keys to filter the query nodes.

@bplatz: we’re not going to add any routing abstraction like that. But also important to not create complications for those who wish to do so.

isn't routing basically union? can be this or those components and i only render one?

but based on your earlier statement - which again I don’t fully understand - there seem to be elements that aren’t needed (as far as I tell at the moment)

I would not introduce routing components or anything like that

sorry for coming with some hand wavy half knowledge shouting into you convo

I would implement this simply as a filter on the root query

but you may have determined a reason why this doesn’t work which you haven’t yet stated

I mentioned a route component, yes. I thought there might be other logic required at a nested route node, but I was/am thinking through what would be required for my app.

The component would be a simple reusable part that knew were to insert a nested route inside the dom/component tree, but that part is outside the scope of IQuery filtering.

It was focused on render.

Om 1.0.0-alpha15 released, includes some tweaks you can tire kick :shared and :shared-fn now

@dnolen: no reason yet that it will not work, that is the path I'm headed down and I'll say something if I run into an obstacle.

@bplatz: cool, sounds good

@bplatz: off the cuff, the primary issue will probably be performance

for this use case where the root wants to control the query it may be interesting to actually diff the query itself

to figure what needs to change

When considering a typical navigation structure, most of the differentiation happens near the root (your main nav). It is possible limiting the scope to just that is "enough" to reduce the query down, as opposed to having to be precise all the way down to the furthest leaf.

@bplatz: right it might not be a perf problem at all.

@dnolen: talking about perf, do you think Om.next is suitable for apps with constant animations (like Musicoacher)?

@wilkerlucio: yes

being as fast or faster than React is still a goal

“naive” React is what I mean of course

cool, thanks for info

just released 1.0.0-alpha16

included fixes so that remote integrate with DataScript is feasible

i.e. transacting remote pulled entity tree (from Datomic) into DataScript

also the last two releases include devcards integration

it’s just a start but already pretty cool

https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/tutorials.cljs

for example here are three of the tutorials as defcards

makes it much simpler for me to see regressions at a glance

thats pretty cool @dnolen

@iwillig yeah @jannis has already demonstrated how easy it is test components in isolation

this gives you the beginning of reconciler mocking

would like to get devcards history control hooked up here as well as better way to visualize the state

but this is already a much better development / testing setup than I ever had in the past

@dnolen: I just pulled master and tried lein cljsbuild once dev. It fails with this error: Exception in thread "main" java.lang.AbstractMethodError: cljsbuild.compiler.SourcePaths._find_sources(Ljava/lang/Object;)Ljava/lang/Object;, compiling:(/tmp/form-init38129677347927342.clj:1:71)

It depends on latest ClojureScript, you need to bump your tooling

See the 1.7.170 announce

Would it make sense to bump the version of lein-cljsbuild in project.clj?

yes

I've bumped that to 1.1.1-SNAPSHOT and now I get java.lang.AssertionError: No ns form found in /home/jannis/oss/om/src/main/deps.cljs. What version of lein-cljsbuild. Probably still missing something at my end.

you need 1.1.1-SNAPSHOT

make sure you clean your build

that error makes no sense

would need to see the stacktrace

Did that with git clean -xdf before running lein cljsbuild once dev. I'll paste the backtrace somewhere.

http://pastebin.com/et5bTWrZ

@jannis just looks like a cljsbuild bug it’s trying to load deps.cljs for some reason

no idea why

I would report that to the lein-cljsbuild repo

Will do

Ah. Running lein cljsbuild isn't even needed to run the devcards. scripts/figwheel.clj is what I was looking for.

@dnolen @jannis that is https://github.com/omcljs/om/issues/449 in action

well, without the jar part .. but still a source-path seems to be wrong

deps.cljs must be at a source root, it will otherwise be interpreted as a normal cljs ns

which it isn't

project.clj looks a bit outdated. It still refers to "src/dev". And perhaps deps.cljs can go away and be replaced by an {:externs [...]} compiler option in the "dev" build.

@jannis check the source paths of your build

it probably contains /home/jannis/oss/om/src when it should contains /home/jannis/oss/om/src/main

@thheller: No, the cljsbuild build contains {:source-paths ["src/main" "src/dev"]}: https://github.com/omcljs/om/blob/master/project.clj#L30

hmm maybe cljsbuild picks up paths from another target

the other targets still contains "src"

FWIW, I was receiving a ICollection protocol error on alpha 15/16 and narrowed it down to me using the stubbed out :shared with an atom prior to you adding enhanced support for it. I bring it up because the stack trace doesn't do much to help isolate it the issue. An assertion for map? on whatever is put into :shared would have helped me, although with the enhanced support I would not have put an atom in there to begin with.

wow lein is so annoying in this regard

should be inclusions not exclusions

anyways deployed 1.0.0-alpha17

@jannis ^

which removes all these unnecessary files

@bplatz: here is an implementation of what you described. a) union query in the “routing” component and b) parse-time filtering of the query based on current route. a) https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs#L111-L130 b) https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs#L43-L47

@dnolen the problem is probably that there are some build targets still specifying :source-paths ["src" "test"] which is incorrect

but cljsbuild gathers the all together when running jar

I see no reason why these files would be on there otherwise

@dnolen: It builds after making this change on top of alpha17: https://gist.github.com/Jannis/307e03a461e9b7cc26e3

@jannis changing the :source-paths bit doesn’t make any sense to me

it's superceded by jar-exclusions

@dnolen: It doesn't? There is no src/dev in the repo anymore, so lein cljsbuild once dev will fail, not finding it. I guess lein cljsbuild doesn't know about jar-exclusions?

@jannis I don’t know what you are talking about

if you’re talking about running cljsbuild commands from with in the Om repo

that’s not something I’m concerned with at the moment

Ah. Yes, I am. They are still mentioned in README.md so I supposed they are expected to work. But then again, the dev task is really not that interesting. The examples still build fine.

@jannis yeah I’m pretty sure I’m going to convert all those examples into devcards

how that’s handled today is very tedious and error prone.

but that’ll probably happen after beta

Cool. I agree, that's a good way forward

I'll shut up then

Hi all, I have an app running with om next which works nicely without any optimizations. However when I stick in :optimizations :simple I get an error for one particular user interaction which says "Assert failed: (reconciler? reconciler)". Does this scream out user error? If so is there anything in particular I should be watching out for?

Apologies if this is in the wrong place or too easy to solve!

@jannis yeah that won’t work you should read over @bhauman and I’s thread from a day ago in #C03S1L9DN

the state stuff isn’t going to work for Om Next

@jannis if you have questions you should ask @bhauman I think he understands the issues pretty well

@dnolen: I skimmed through it yesterday or so. I thought one of the issues was the absence of a "history hook". I don't fully understand why but the above snippet seems to make that work. It probably swap!s the state returned by (om/app-state ...) and when defcard then rerenders the RootView (it calls the anonymous function whenever the card state changes), the reconciler has that state set. Not the cleanest way I'm sure but it seems to work.

@jannis it really cannot be made to work with the state feature at the moment

Om Next needs to control the root

and if devcards is feeding it state the whole thing breaks

You mean calling swap! on the app state held by the reconciler breaks things?

yes devcards listening on the state atom is just broken for Om Next

not interested in hacking that to make it work either

so we’ll probably need some kind of custom card - this is what @bhauman suggested

Hmm, ok. Both tutorial examples work with the above trick, including history, so I thought that could be the solution. Probably not then 😕

@dnolen, ok now this is under 150 lines, maybe enough short? https://gist.github.com/leontalbot/1d57bb05c063a989757c

the mutation does change the state, but the view doesn't update 😞

@steveb8n Thanks! in the updated link, I do the transact at the second level now. Still the view doesn't update 😕

@leontalbot: Move the :poll/questions out of the () in the transact! call.

[(selections/update-radio {:name ~id :value ~value}) :poll/questions] is what you want to pass in.

@jannis You did it!!

thanks a lot!

any other advices?

@leontalbot: Just minor things about coding style. Like: no need for apply in (apply dom/div nil (map question questions)) and perhaps (for [x a] ...) would be more readable than (map (fn [...] ...) a) in render of Question, could use more descriptive identifiers for answers than 1, 2, 3, 4, 5 (e.g. :not-interested, :yes-please) but the Om side of things look good to me.

Thank you @jannis !

@jannis: be careful about dropping apply with lazy seqs...works in dev mode, not in production

anyone know if repeated browser requests for favicon.ico and om rerenders might at all be related?

(from what I've seen on earlier, at least)

using mapv is fine, since it isn't lazy

(this is in om.old)

@tony.kay: What do you mean by "dev" and "production" mode? Optimizations?

hrm suprisingly neither Relay nor Falcor seem to deal with the temp id problem?

weird. Seems like nearly everyone will hit that?

or anyone relying on db generated ids, that is.

@jannis using the minified version of React causes different behavior in regard to lazy-seqs, some bindings om.next uses will be incorrect which may cause errors

@jannis (doall (for ...)) or mapv like tony suggested prevents that

@thheller: would like to see a reproducer for that

I haven’t seen that in the any of the examples that I wrote with React with advanced optimization on

just include the minified version of react

and use a for

already did that many times

or any lazy seq really

no issues

for loops, map etc.

I have only seen apply in your examples

ah yeah you cannot return lazy seqs React doesn’t support that

children can be an ES6 iterator

but you must set this explicitly

yeah (doall (for ...)) works

and Om doesn’t not expose this in any way at all

(for ...) does in dev mode

@dnolen no it works out of the box

unspecified behavior far as I know

unless you’re talking about this signature - and I have not seen this documented

(ctor props Array|Iterator)

no the ES6 iterator is official as far as I can tell from the code

and all my tests confirm that

I’d don’t really care what the code says

I only care what React docs say

if something says you can return a ES6 iterator as element that’s news to me

children is a different matter

not saying you can return it as an element

you can't

then what are you talking about?

but it can be ONE of the children

(ctor props Element…)

that’s the only legal thing

then you are saying you can return it as a valid Element

and I haven’t seen anyone say you can do this

(div {} (h1) (doall (for ...)) (div)) works

that’s what I’m saying

you are returning an iterator as a React element

no?

maybe that is supposed to work but I just haven’t seen anyone say this allowed

or if this is weird feature to support JSX

no idea other than that is makes sense to support it this way

and it all works perfectly as long as you are careful with lazy-seqs

yeah I don’t care if it “make sense"

show me the docs otherwise you writing code Om doesn’t support anyway

@dnolen I have no interest in convincing you whether something is official or not

I was just warning @jannis about lazy-seq, just like @tony.kay

if your solution is to tell people to use apply I am fine with that

right my point is to separate out weird stuff like context or willReceiveProps

to reduce confusion about what parts of React are relevant

not sure how that is related

anyways my point is you can only return elements in Om

I can’t find any documentation on what the semantics of ES6 iterators are in React

other than children

but Om doesn’t let you just set that

anything suggestions other than these facts is just muddying the waters

yes and I'm saying that [child1, child2, iterable, child3] also works

and many people are using that fact already

and that is a React thing, om is not affected

or doesn't care for that matter

just got to be careful with it is lazy, due to different behavior in react.js and react.min.js

that is due to react.js verifying the children immediately (thus forcing the lazy seq) ... and react.min.js not doing this and thus forcing the lazy-seq outside render

which breaks the binding om.next uses in render

I threw away the repo where I verified this ... but you can verify that yourself if you feel like it

https://github.com/facebook/react/pull/2376

that seems to cover it

not quite, but it did make me look into what React supports which I never actually every used or understood

prior to that React let you return elements or JavaScript arrays

I’m assuming the later was present for template splicing

yeah that changed in 0.13

the arrays can be arbitrarily nested

but need :key

the ES6 bit is just an extension of something they started permitting

yeah so this is making me think we should just force lazy seqs

probably a good idea to do that automatically

manually takes a bit of discipline and is easily missed

not sure how to do it efficiently though

the N is never going to be very big

so I’m not concerned about that

already did all my testing with apply which is dog slow, but it’s not the bottleneck

React is as usual

@thheller: apologize for being so argumentative. It’s a bit frustrating that React doesn’t state clearly anywhere how it’s supposed to work

in Om Next I’ve definitely stayed far away from implementation details this time around

this is just a legitimate Om bug

@dnolen no problem .. I spent more time in the React internals than I care to admit

yeah there’s a couple places where we dip our toes

but stuff like that is just a ticking time bomb

literally every release has broken something

and I mean internal stuff (breaking public stuff is about progress etc.)

yeah we should just do a cljs react already 😉

ha!

don’t want to work on Android or iOS

hehe yeah me neither

anyways .. if you implement something that forced lazy-seq remember to not throw away microseconds

https://www.youtube.com/watch?v=JEpsKnWZrJ8

but React already throws away plenty of them so it probably really doesn't matter

fixed https://github.com/omcljs/om/commit/40e5c2c0588d9b4287c17c05e913f72ffdbd9894

@thheller: inadvertently you forced feature enhancement since I never knew it was supposed to work this way

now we have a good splicing story

om.dom/* needs to do this as well though

uhm doesn't your test miss one level?

and remember this ALWAYS works with react.js since that already forces all children for you

react.min.js is where things get icky

since it doesn't use ReactElementValidator

which is what forces things

try (for [it [1 2 3] :let [_ (prn [:doing it])]) (dom/div nil it))

the log appears at different points in time

depending on the react version used

@thheller: ah right om.dom

Really, react.min.js behaves differently from react.js? I thought minifying was about syntax, stripping unused stuff but not changing behavior? Ugh.

@jannis no the dev version of react does a lot of validations to warn you about errors

these get stripped away in the production version

much like :elide-asserts in cljs

@thheller: Well, that's one thing. It's another not to iterate over lazy sequences to collect everything in one version but not do it another, even if that is just a side-effect of stripping validations. Boo. Well, if we can fix that in Om that would be awesome.

well, React doesn't know what "lazy" means .. so you can't really fault them for that

Hah, okay. You've got a point there. 😉

FWIW I wrote a macro in my stuff for for (eg. (dom/for [it [1 2 3]] ...)) that is just a normal for wrapped in (doall ...)

solved the lazy problem for me 😛

Sounds nice

but I only use that for so it works for me ... doesn't work so well if you use map as well

or anything that is lazy

for just looks nicer to me when the body is always something like (my-comp it)

I'm almost exclusively using for... yeah, definitely looks nicer.

Wouldn't it be nice to have that as forall in CLJ/CLJS?

is the macro

@jannis: @thheller: and David just patched it to force children for you...see above

@tony.kay: yeah but it is incomplete 😉

oh, did I mis-understand?

no, he is probably working on it right now. need to adjust om.dom as well and make it recursive

oh, I see. Yeah, I was just reading the factory/force-children stuff, but yeah I missed the om.dom comment

reading too fast

yeah we probably should have opened an issue the last time we talked about this

lost quite a bit of context since then 😛

yeah, I was trying to remember that React commit...glad you found it

@thheller: force-children is recursive unless you’re seeing something I’m not

but yeah working on the DOM bits

a modification of a minimal example to get om-next rendering server side: https://github.com/thos37/om-server-rendering

#(cond-> % (seq? %) force-children) (dom/div) fails (seq? %) and won't recur ... but adressed if you add it to all om.dom

but it’s also wrong

just gotta be careful with any other normal react component

😛

force-children is wrong, fixing that

but I already changed all the dom nodes to call it

if say something like react-material-ui is a child of an om component, that won't force anything

right but I don’t really care about the nested cases

if you instantiate something and pass it through a regular React thing

all bets are kinda off

yeah but people are still going to do that

we can of course support higher order composition as long as your not doing it lazily

they might, but I’m just less concerned because the problems are much bigger than lazy sequences

hell we all do it every time we use (dom/div nil ...)

right but that case is covered as I said

by changing all the dom functions

and all the dom macros

yeah, just saying there might be react components people use just like dom/div

and those won't be forced

no but that just not something I care about

so people still need to be aware of the issue

make factories for that stuff

and use the same simple thing

as long as the standard thing works, we can document this issue for integrating 3rd party React stuff

can probably even provide a factory helper

to automate this

yeah I just settled on the macro since that always works in all cases

well until you use map

plus it uses less resources 😉

https://github.com/omcljs/om/commit/2adb2bfbbee5138b1bde82c5e6d22bf9fbe17a14

should be fixed for real now

yep just verified in a small advanced example

deploying a new release

1.0.0-alpha18 released