@tmorten: you might find some inspiration here https://github.com/stevebuik/om-next-ideas/blob/efb9502eb44deae70a63c93af1a2c9f68e46759e/src/cljs/om_next_ideas/app/core.cljs#L55

it correctly migrates tempids and queries work - can be verified in app or in integration test

Hi, I am trying to get some stuff done with clojurescript/om. Essentially I want the state to have file input and on-change do something with the contents. This is what I have - I ideally want to print something out to the console: https://www.refheap.com/114034

Hi @shriphani

(1) It's unlikely correct that you put dom/input into state. Was there specific reason for that?

Hi @andrewboltachev - sorry my cljs is quite rusty - I only fiddle with the browser occasionally.

and my react is quite poor as well

how would you recommend I do this ?

so, you're to use modern HTML5 shims to get file content

well, then you're state is likely to be empty

my end goal is (i) user uploads a file that is a bunch of cljs maps (ii) we parse it and render it (iii) user edits it and we save it back to disk.

@andrewboltachev: yes.

it is empty initially.

so do you suggest I put this outside the state and on-load update some other state - which typically renders the parsed cljs ?

@shriphani: 1 sec

sure take your time

@shriphani: btw, do you want to use Om or Om Next?

umm which is better ? I just googled for a tutorial and went with whatever came up

well, you're using Om already

om/root is Om function

well I have written 2 expressions in it so it is not like I am committed.

btw, did you go through tutorials?

e.g. this https://github.com/omcljs/om/wiki/Basic-Tutorial ?

@shriphani: well, anyway there's something that should work https://www.refheap.com/114036 (or not, you test it)

just the first one that gets you a contacts app.

@andrewboltachev: weirdly I get no console output when I use your example.

@shriphani: :onChange

that does produce output on the console

@shriphani: so, how's it now?

yep, here we go

btw, what browser are you using?

chrome

also I fiddled with it enough to get access to the files selected

chrome's nice

@shriphani: Please note that I've used js/console.log, which is better at prining raw JS values. You're on Google Chrome it would be possible then to explore it easily

yeah I noticed

Whilst println is better for CLJS values

I’d been using println till then and it was a plainly worthless

thanks a bunch

np

Also, you might check out React's main tutorial for better understanding https://facebook.github.io/react/docs/tutorial.html

At least I did go through it

@steveb8n: sweet! This is good stuff. Do you think the way it works using the default-merge is by design?

@andrewboltachev: ok I was able to print out file contents to the console - I was wondering - if I make another component and make it render something in app-state, it should pick it up once the file-load is done correct?

@tmorten: I didn’t dig deep into the various merge options. I saw merge-tree in other peoples code so I went with it. seems to work in that project and the app I’m working on

Does anyone have routing in Om Next working?

@andrewboltachev: I’m halfway through using this technique https://github.com/jdubie/om-next-router-example

looks good so far

thanks @steveb8n !

sorry @shriphani Just were really busy

@andrewboltachev: no worries - I actually got it done.

thanks a lot for the pointers.

it looks pretty ugly.

one nice trick I’ve noticed is that if I match the server routes to the client routes then I get automatic support for deep linking into the app. that’s a nice property

huh, so cool https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs#L41

I didn't think about delegation

i.e. to invoke parser from read-fn

@steveb8n: though it fetches data for all routes at once, doesn't it?

@andrewboltachev: yes but that works in my current use-case since my routing is for editing different parts of a graph in one page

got it

might not suit other types of apps I suppose

I tried to play with set-query!, and that were working just ugly

agreed. I’m waiting to see all that discussion settle on a solution before exploring

i.e. probably it can be called only from some places/at some moments with specific params

there is something here: https://github.com/omcljs/om/wiki/Routing-Support

exactly, it seems like those “helpers” are still being evolved by various folks in this channel

aha

I haven’t seen another sample app showing the top down approach yet so I’m sticking with total query until then

@steveb8n: do you have recursive component btw? for graph node?

or, reading fns resolve that stuff

'cause graph isn't tree

no recursive ui in my app although may need it in future

can't get query params working

@steveb8n: don't you have ones?

suddenly, works

like that "finger to the sky" programming style

@andrewboltachev: do you mean om query params or route query params?

Om ones

well, I'll map route query params into Om ones

@andrewboltachev: I am using them but don’t have an example in my public github project. you have played with this right? https://awkay.github.io/om-tutorial/#!/om_tutorial.D_Queries

queries? right

Like I said, Om ones work now

I’m doing the same. Using closure to parse params from url in a cljs parser multi-method and calling that when building remote queries in the client parser

this is nice also because when testing I can replace the cljs multi-method with a clj mock for reading the browser url

Seems bidi doesn't have way to handle ?a=b&c=d -> {:a "b" :c "d"}

exactly, that’s why I’m using closure with bidi

Wait, 'cause it doesn't have?

use bidi for the path part and om query for the params

routing started to work, but now it doesn't read from remote...

@steveb8n: btw I agree on the point: "top-down" is what always wanted

@steveb8n: ah, that's a nice solution!

Following the om tutorial with "1.0.0-alpha28", is the om/from-history fn broken ? it always returns nil for me.

@nha: it’s possible, but you need to be on a latest version of ClojureScript for it to work correctly for sure

Ah right. Will update

Alright it is working now with the latest clojurescript.

(maybe I was doing something wrong before though )

Ok looks like it is loosing it after a Reload (from boot-reload).

Not that surprising I guess.

should I ask questions about om/next here or in #C0DT1AZD3?

@asolovyov: here

cool! so here is the thing: I return {:value nil :auth :non-interactive} in my read function, and when I do (my-parser {:state (atom {})} [:whatever] :auth) I get nothing. When I read remote-sync-tutorial I got an impression that it should return :non-interactive? Anyway, :remotes of my reconciler are [:remote :auth] and :send function is never called. I'm not completely sure how to debug this...

Have you read the Om tutorial on db format, reads and parsing?

@asolovyov: ^^^

@tony.kay: I think I did, but surely I've tried to jump before myself?..

In the community resources in Om wiki.

if you are returning :value nil and expecting a good result from read, then you have not read enough

when I do (my-parser {:state (atom {:whatever :x})} [:whatever]), it returns my :whatever

well... I'm not expecting a good result, but even if I return anything in :value, I get nothing for remotes

that's what I'm puzzled about...

for remotes, you need to return a :remote key, not a value

you have a choice: :remote true, or :remote ast...where :remote is you remote name

and ast is a query-like thing?

ast comes in env

it is a query turned into an Ast so you can transform it

see query->ast and ast->query

OH!

Ah, I see you did return a remote...you just called it auth. Yeah, you want an ast, not a keyword

{:value nil :auth true} worked

right, it is sensitive to real booleans

hehehe

truthy isn't good enough

ok, that's a bit more understandable

what do you usually return in remote?...

true if I don't need a transform, and an ast if I do

got a meeting...good luck!

ok, thanks!

@asolovyov: The steep learning curve of Om Next is what makes it so fun

@drcode: 😄 well, I really like when I can jump in and do something :))) it's a bit different in this case

@tony.kay: Thanks btw for your resources, helped me through several difficult spots in the last couple of weeks

I wonder if it's possible to render stuff without explicitly defining factories everywhere...

I'm merging in external novelty with om/merge! and re-rendering is working great keys explicit in the merge map. However there are other keys I want to also force re-rendering on.

Is there a utility to force re-render of all components of a given key (or ident?).

I don't see one in the documentation wiki anyhow.

@bplatz: no you do that by putting those keys into the transaction

There is no transaction, just a stream of datoms. I can wrap everything into om transactions if need be but I was expecting merge! To help avoid that.

So if I understand it correctly, om/merge! works well but only for items that affect a single key (or ident). If you have novelty that might impact multiple keys, you need to instead use om/transact! as it is the only thing that allows multi-key re-render.

And if that is correct, I'm not sure why not just wrap all external novelty in om/transact!, I can't think of a real need for om/merge!.

somewhy when figwheel reloads my app, I get an error that reconcile! can't call ((:render st)), where st is {:normalized false, :queue [], :sends-queued false, :queued-sends {}, :queued true, :t 1}. I wonder what's that and how do I fix it?

@asolovyov: that's probably caused by multiple calls to add-root!

e.g. on reload

@anmonteiro: ah! that could be, but what's the right way to re-render then?

@asolovyov: I've recently written about writing reloadable code in Om Next. See if this helps: http://anmonteiro.com/2016/01/writing-om-next-reloadable-code-a-checklist/

you don't mention :jsload-callback anywhere...

"I imagine variations of it can be used as a Figwheel reload hook."

I do, just before the code snippet at the end

ah right

it also helps if you're running Om's master

ok, force-root-render sounds ok

but I've removed jsload-callback right now and everything works fine...

that's interesting

@asolovyov: you don't need js-reload if you're calling that example function on reload

e.g. you have an invocation in your code

right, I'll build something like that

nice, now everything's good, thank you!

If I'm using datascript to store my app state, is ON's reconciler able to merge in external novelty from the read fn for me, or do I need to extend/adapt/something the reader?

Also, though I'm late to the discussion, w.r.t routing in ON, I have one <div> that I swap various components onto, as opposed to having one root component that contains every other component (which is what it sounds like other people are doing, but I'm not sure)

So I'm curious how you all have been handling form data in om.next. In om.prev, I would mutate the individual keys in the cursor...with Om.next I've been loading into local component state and using a single transaction to update the record data. Anyone else doing anything differently?

At one point I had all my forms in my app state using [:form/by-id “a-form”] which worked ok. Then when you submit or whatever you can deal with mapping that to the actually “source of truth” data in the app state.

Seems like I've been doing it wrong by loading into local state, and perhaps (according to React docs), I'm doing it anti-pattern style (wouldn't be the first time for me)

@tmorten: Are you saying you should om/transact! every change to the form, or that you should store the use input locally then transact! it when the user submits it?

@futuro: Essentially, that was om.prev style, transacting on every change of key inside the cursor {:onChange #(om/transact!...)}. Om.next, I'm under the impression that storing the input locally (om/update-state!) (om/get-state) and then transact'ing the contents of local state when user submits

I guess that was "one" of the styles of om.prev...I should say

@tmorten: gotcha, thanks

That's what made sense in my head, so I'm glad to hear about how other people are doing it

I've been doing the later with om.next, and according to the React docs, that leaves "two" sources of truth to the app-state...unless I'm reading it wrong (which is certainly possible)

hmm...yeah, I could see that

https://facebook.github.io/react/tips/props-in-getInitialState-as-anti-pattern.html

The only way I know how to pre-load the initial values of a form is via getInitialState

then mutate the local state via onChange call

My query->sql compiler is coming along nicely. You can pull entities from a db now: https://gist.github.com/jlongster/df56f4f615ece93b8200

it ensures to always only generate a single SQL query to get everything

Looks very promising

One thing I have been wondering lately, what if we could put the SQL as co-located queries on components

@iwankaramazow: not going to happen in Om at least

it'd require a whole different engine for tracking queries, etc

the company where I work is heavily sql-based

bringing datomic pull syntax, would be some form of treason

@tmorten: based on that documentation, it looks like passing values from parent to child through params and storing that state is the anti-pattern,

but I think locally storing state generated with the component itself isn't, as you've got one source of truth

the component itself

@iwankaramazow: I’m sure that’s the case, but just not interested in that at all.

@futuro: I do see that. However, I essentially have a 1-1 map of local input fields in local state that are also in props. I was thinking that was where the problem is. Instead of just using those props to initialize the local state.

@dnolen: it was more of a thought, not sure if a truly 1:1 client-server environment is desirable

@tmorten: hmm

And from what I can tell, it wouldn't make sense to have a (om/transact!)/mutate method on every input element's onChange event

that seems excessive

it seems like a better idea would be to sort out how to put the single source of truth for the life of the component inside it's local state, instead of spread across it's parent and local state

that's my first thought, at least; your code might not bend so well to that

@futuro: agreed. That's why I think the way to do it is load up your components local state from props (getInitialState) and then when user commits the change via submit,etc, have a update mutate method to reflect that change in app state. That's how I am doing it and seems legit

Is there any way of setting the query params when creating a child component in the render function of the root component? Still working on routing, and while I can get the root query to fetch the correct parametrized data, I'm unable to parametrize the created child component, and thus it will not be able to use the data that was fetched for it. Thought I could just apply om/update-query from the root render function after creating it, but apparently it isn't a component at that point, or at least from that vantage point.

Ok.. figured out a workaround for that. Passing down the parameters to the child component via a computed prop and apply update-query! in componentWillMount.

@drcode: Welcome. Glad to hear it

@dnolen: You were asking earlier about a use-case for focus-query to be in the public API. We have one. We wrote a helper for lazy loading (e.g. (load-field this :comments)), and it extracts the ident and query from the component, uses focus to get the portion of the query that is interesting (the join on :comments in this case), and anchors the query on the ident.

@tony.kay: ok! PR to make it public welcome

k

what exactly would you want modified? The doc string?

I mean, it is already visible

or just documentation

k

I mean rather

in the wiki

oh, ok

anybody can do it really - but I’m fine with the official stance on it being

yes you can use it