This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-04-05
Channels
- # beginners (23)
- # boot (84)
- # braid-chat (2)
- # bristol-clojurians (1)
- # cider (53)
- # cljs-dev (34)
- # cljsrn (13)
- # clojure (138)
- # clojure-dusseldorf (5)
- # clojure-italy (1)
- # clojure-russia (164)
- # clojure-uk (41)
- # clojurescript (80)
- # clr (2)
- # core-async (6)
- # core-logic (25)
- # core-matrix (14)
- # cursive (10)
- # data-science (4)
- # datomic (4)
- # emacs (3)
- # funcool (6)
- # hoplon (127)
- # jobs-discuss (4)
- # keechma (36)
- # ldnclj (5)
- # lein-figwheel (5)
- # off-topic (5)
- # om (155)
- # onyx (72)
- # overtone (16)
- # parinfer (39)
- # planck (3)
- # protorepl (1)
- # re-frame (11)
- # reagent (5)
- # untangled (22)
Is there a solid comparison of using Om Next to Reagent with Reframe? Seems to be the top two competing client side options
Nothing solid. Someone once looked at the demo Colin Yates put together of doing a table component/s with reframe, and pointed out (in terms of Big O speak) to Mike Thompson that doing the same thing would be less complex with Om Next.
Is there a way to normalize the initial app state with parts of the query or the whole query not even on the root component yet? let's ignore the fact (for now) that parts of that query are on lazily loaded components which aren't available yet
it occurs to me that in http://anmonteiro.com/2016/02/routing-in-om-next-a-catalog-of-approaches/, only the union query approach doesn't have this problem
actually that example doesn't use normalization, so not sure how that would work exactly
@seanirby: A Github: https://github.com/yatesco/re-frame-stiching-together. The conversation was in the reframe channel as I remember.
cjmurphy: thanks. learn anymore about follow-on reads since the last time we talked?
There was a chat in Untangled. I put up an example of them being used and someone said 'why did you use the customer key?'. Reason:- it doesn't matter which key you use - they are all in the root component anyway. (Assuming default db format).
I've since taken to expecting all to be re-rendered after every mutation, and not bothering with follow on reads by putting all mutations at the root a la Kanban. And sometimes using local state (with channels) where I don't want the updating upon every mutation to be happening.
the follow-on reads I was using were causing some bad performance issues for my app. these particular components were triggering mutations with a follow-on read that affected a very large component. i was able to sidestep the issue by not actually using follow-on reads but getting the large component via class->any
and transacting with that instead
The example I gave had only the item (in many, under a parent component) being updated, which is good, but I can't get that to happen reliably.
Hmm yes - its difficult to work out what the logic might be. I hope one day we will be able to debug to answer the question - 'why is this component being re-rendered' when it is unrelated.
They were just some simple checkboxes. Github's gone to sleep for my profile otherwise I'd show you.
@cjmurphy: this is what I've been doing to avoid the follow-on read https://github.com/seanirby/koeeoadi/blob/master/src/cljs/koeeoadi/components/codepicker.cljs#L11
Are you using an ident there as the follow on? I never could get one of them working.
no theres, no ident or follow-on read happening. just getting the component that actually needs updating.
Thanks for that code. Github is back and I found the
(om/class->any reconciler CodeDisplay)
you use. Will experiment with that idea on my checkboxes, which are still all always being rendered, despite the fact I couldn't achieve this problem on a minimal example:
.@cjmurphy: so in that example your GraphLineSelectionTextbox doesn't get rerendered ?
The other items don't get re-rendered. The one that was selected (or de-selected) does. So it works as you would want. And shows that an irrelevant follow on mutate read does the trick. So it works, but it is confused!
Can anybody remind - what was a problem with cursor approach in the original Om? I remember David mentioned it in some talk, but I can鈥檛 find it
artemyarulin: never used om extensively, but the quick start mentions that cursors cause a deep coupling to the app state
It could be this talk: https://www.youtube.com/watch?v=ByNs9TG30E8
Original om cursor are tree structures. But in applications you are not always presenting data in a tree form. Like you want to show the same data in different views. If in those places it's possible to change that data it's quite hard to synchronise those changes
Thank you all!
Odd question perhaps, but: despite being an "alpha" version, is the om.core
in 1.0.0-alpha32 considered production ready?
@peeja: I'm pretty sure you can use it in production
IIRC there has only been 1 change targeting it
which was to improve compatibility with React 0.14
this to say that it's pretty much the same as 0.9.0
only with React 0.14
what downsides would there be for representing "unique idents" as [:key] rather than [:key _]?
upsides: get-in and update-in just work. no need to use ~' in syntax quote or patch om to check for ns/
I guess it would mean that ident? should be extended to include vectors of length 1, which seems potentially troublesome
yeah you wouldn't be able to distinguish between QueryRoot and IdentExpr: https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc#L15
you don't expect QueryRoot and QueryExpr in the same places, so there is no need to distinguish there
i'm writing a backend in a statically typed language and i just limited it to the types that might reasonably be used as an id
just like the EdnValue in ParamMapExpr, where it makes more sense to use all kinds of stuff
well in my case i'm writing a backend for a relational database, where the ids tend to be simpler types, so i don't see any reason to worry about it
you're right that you would be able to figure out what is meant with that scheme, not sure if there would be any other problems
is there a way for nested components to query for top level data in the app-state without an ident?
Is there any reason why it's not possible to do goog.style/setStyle on om.dom/img elements? (or maybe Im doing something wrong)
Well, the whole code is filled with comments and junk but basically this is inside a render function
(dom/img #js {:id "prufa" :src (:photo ((:slides @app-state) 0))})
(and the picture is visible) and in the repl I am trying this (style/setStyle (gdom/getElement "prufa") :height 200)
or this (style/setStyle (gdom/getElement "prufa") "height" "100")
@hlolli: om.dom
"elements" are just React Element instances, they're not HTMLElement s
oh, actually your code is selecting an HTMLElement
Well, my final goal is actually to try to create a basic slideshow with goog.fx.dom and seemingly for goog.fx.dom.resizeHeight a update style function is needed. It's somethimes diffucult to see the interoperability. Becayse the image href is inside a app-state atom, the image is shown by the way so that parts works.
by the way
(.-height (style/getSize (gdom/getElement "prufa")))
returns 600 so the brepl is sure connected.
ps. bit of correction, im actually trying to use .resizeWidth (.resizeHeight doesn't exist seemingly).@anmonteiro: when manually normalizing initial app-state, should I provide :om.next/tables
to the app-state (with :normalize false
on the reconciler) ?
wait, what do you mean by "manually normalizing"?
In the context of a router, let's say a user wants to supply initial data, that needs to get normalized for Om's graph magic. Problems: a) the query isn't on the root yet b) if there's code splitting, there isn't even a component available to get the query/ident for normalization. I'm might throw my router into an open source project, it's something I would like to somehow solve before doing this.
Yes I got that part
but you're not actually "hand-normalizing" your state, are you?
It's perfectly acceptable to call tree->db
on a component that's not the Root
I've done that countless times
Yea, but tree->db
needs a component, what if it hasn't loaded yet as a <script>
? Seems strange to load it just for normalization
I might be overthinking stuff
hehe yes! I've been working with that for some time now. I kinde-a gave up. I was able to animate, once, but animating the second time, never worked (cyclic animation).
but I was able to change style with "display" "none" in goog.style/setStyle so Im getting closer to a solution.
not really sure yet whether that example fully works, but I haven't found more problems after adding om-bound-fn
anmonteiro: it would be lovely to see a "routing with unions" example which uses normalization
@tomjack: hrm, not sure what's the real problem there
the example would just be the same as I've written
you don't have any Ident, and your union query map is not associated with a component, which seems to cause an error ("Union components must implement Ident")
however, with :normalize
set to true
in the reconciler, and the initial state normalized with the first route's data
right, add the needed idents wherever they're needed
my post didn't focus on normalization or URL routing or any of those details, because the focus of the post was just to showcase different approaches people can take to implement routing in general
sure, thanks for that post. I will share my broken attempt to add normalization sometime
happy to look over it, and try to figure out what you might be doing wrong
putting (ident [this] [something ']) seems to cause tables with { ...} after normalization
that's expected
if you use [:by-id 2]
you get table with {2 ...}
, why wouldn't you get a table with {_ ..}
if you use _
in an ident?
I expected no table, really, because db->tree looks for a "unique ident" like [:foo _]
in [:foo]
, not [:foo _]
, as in "thinking with links"
so "you shouldn't return 'unique idents' from ident" makes sense to me, but then it's unclear how to add normalization to the union routing example -- unless we stop using unique idents?
I don't understand what you're trying to say
db->tree
looks for a "unique ident" in queries
there's nothing preventing you from creating idents with [... _]
@hlolli not sure without playing with it, but I would try creating an Image component with a :keyfn specified in the factory
otherwise react-motion will just think it's the same image already animated, but with a new src
ok, so I should pass on the index from the root component into the factory of Image-slider?
ok, I may add to the expectations of my skills that Im still bit of beginner. Thanks for this tip.
in a factory, is this leagal (om/factory UIComponent {:keyfn [:key1 :key2 :key3...]}) ?
so it's only possible to pass one property to a factory, Im probably misunderstanding.
now I guess one merge!s {:app/routes [{:routes/ident :app/home ...}]}
instead of {:app/home ...}
for initial state normalization we can add the :app/routes query just there. then for e.g. merging in a new route I guess we can pass that query again in the merge!
@anmonteiro: In the solution you suggested yesterday
(defmethod read :root-query
[{:keys [query target parser ast state] :as env} k params]
(let [val (parser env query target)]
(if (and (= target :search)
(not (empty? val)))
{:value (select-keys @state [:search/results])
:search (om.next.impl.parser/expr->ast (first val))}
{:value val})))
If we want to add more to the Autocomplete鈥檚 Query, say local variables, this would no longer work, no? val
would contain more than one key for starters.
static om/IQuery
(query [_]
'[(:search/results {:query ?query})
:local-value])
I mean, you can use (query->ast val)
today, but your send will receive an invalid query
@uwo: a workaround will be to put all the search stuff under a single key, say :search, so that your remote query expr is like {:search [:search/results :local-value]}
. but this does not seem always desirable. e.g. I have a remote which persists a few unrelated root keys to local storage, and I don't want to put those under a :local-storage key -- I should be able to add bits of state to local storage without changing the rest of my app