This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-17
Channels
- # admin-announcements (4)
- # beginners (35)
- # boot (183)
- # cider (28)
- # cljs-dev (4)
- # cljsjs (1)
- # cljsrn (5)
- # clojure (52)
- # clojure-austin (4)
- # clojure-russia (83)
- # clojure-sdn (1)
- # clojure-uk (18)
- # clojurescript (48)
- # core-matrix (5)
- # cursive (4)
- # datomic (23)
- # devcards (2)
- # dirac (43)
- # editors (2)
- # emacs (4)
- # events (5)
- # funcool (2)
- # hoplon (81)
- # immutant (3)
- # juxt (3)
- # ldnclj (1)
- # luminus (12)
- # off-topic (6)
- # om (72)
- # onyx (32)
- # parinfer (2)
- # pedestal (1)
- # proton (6)
- # protorepl (3)
- # re-frame (30)
- # reagent (2)
- # spacemacs (2)
- # specter (1)
- # testing (1)
- # uncomplicate (3)
- # untangled (15)
- # yada (10)
I spent the day generating an intro video for anyone looking for an overview of what Untangled stacks on top of Om Next: https://youtu.be/CoMyszwN50g
@tony.kay: congrats on the release! looks like a fun thing to study. one point of feedback: the video feels like it moves a bit fast
so my root query doesn't match with the initial app-state but I plan on handling this in the read functions with db->tree
. The problem is that Om doesn't trigger normalization of the app-state until I add in a query that does align with the app-state data. Is this expected?
@seanirby: Yes - you have to put all the joins into the root query that normalization will need. That means there's usually a few extra ones from what you think would be needed.
cjmurphy: ok good to know. any idea why Om can't pick up on the idents needed for normalization through the non-aligning query?
@seanirby: You can have custom queries just for normalization using defui with no render implementation. May be that can help.
No idea. In fact I keep on making the mistake of not putting new ones into the root component as well as where they are supposed to go.
Yeah because it feels icky I kept making the mistake. But I develop with https://github.com/chrismurrph/default-db-format so at least I get told as soon as I forget.
@jlongster: Well, it is intended to be a promotional thing, with follow-up videos that address each area in detail.
cjmurphy: I remember you showing me that. I should probably go ahead and install it 😛
Maybe there's an advantage from not using it right away as good to look at what exactly the default db format is - using (pprint @reconciler)
. But then there's all that lost time when you didn't know what was actually wrong, and it was that you had forgotten (or not so much forgotten but been adverse to) something like putting an ikky query into your root component. Really it was because of all that lost time that I decided to write default-db-format.
om.next=> (zip/root (query-template '[({:join {:union [:foo]}} {:param 1})] [:join :union]))
[({:join {:union [:foo]}} {:param 1})]
om.next=> (zip/root (query-template '[{:join {:union [:foo]}}] [:join :union]))
[{:join [:foo]}]
@dnolen: For my cases, I found a work around. Walk the query, find a union in the query and -> vals mapcat vec
it. It works for now. Thanks for clearing it though!
@dnolen: I think what @tomjack posted wrt. query-template
is a bug
om.next=> (zip/root (query-template '[({:join {:union [:foo]}} {:param 1})] [:join :union]))
[({:join {:union [:foo]}} {:param 1})]
om.next=> (zip/root (query-template '[{:join {:union [:foo]}}] [:join :union]))
[{:join [:foo]}]
the first case
we should be eliding the :union
bit as we do in union queries without params
I've got a fix ready to PR once you confirm my suspicion
Pretty sure this is a bug after having read the query-template
union tests
I'm a bit confused by om/Ident
. All the examples I'm trying seems to work fine even if I omit it
@doddenino: you only need to use idents if you want to normalize your data in the default database format. your app will still work without it, but the database won’t be normalized see: https://github.com/omcljs/om/wiki/Components%2C-Identity-%26-Normalization
@ethangracer: so if my data is already normalized in the right format I don't need it, right?
@doddenino: sorry about those last posts, not sure they’re entirely correct since I’m using the untangled framework which automates some of the reading functionality. I’m not 100% sure whether you need idents if you hand normalize the initial state. You definitely need them if you intend to use db->tree
, tree->db
, or merge!
I see. I think I'll have to study more that wiki article you linked. Thanks a lot for the help
is there a way to use hiccup style syntax with om next?
if not, is there something that abstracts away the need to use #js {} with all of the maps and passing nil if no map is needed
adamkowalski: sablano is what you want
[sablono.core :as html :refer-macros [html]]
and then (render [this] (html [:div.somestyle “blah blah”]))
awesome, thank you
I think I looked into sablono before but i was having an issue with multiple children needing a unique key
how do you show a new component for each item in an array properly so that it doesn’t have the problem?
From the Sablono issue queue: https://github.com/r0man/sablono/issues/40
I see, so you just add the key meta data to each child
can I also do something like this? assuming I have a (defui Person …) (def person (om/factory Person {:keyfn :name})) then would it handle it automatically?
@adamkowalski: Yes I believe ON will handle it for you, as long as every :name
is unique. :keyfn
is what goes to React. The metadata way (alternatively :key
in first position IIRC) of doing it is more for the Reagent crowd.
ok cool, thanks for all the advice.
do you have any advice for coming up with generic unique keys? Because unless I have something immediately apparent to use I sometimes resort to mapping a range the same size as the array, and use that “index” as the key
yeah, it seems like most people do not use hiccup syntax with om next, can you elaborate on why? is it considered not idiomatic code, or is there some inherent flaw that I am overlooking? Because to me it seems like it allows you to express the same amount of information without as much code
I know they have things like :name
in the tutorials, but in real life you can use :id
for everything??
fair enough, I think the reason I was having that issue is because I don’t create a component for everything
if all it does is render, I just create a function which takes in data and returns virtual dom elements
@adamkowalski: syntax is only syntax, des gouts et des couleurs on ne dispute pas (de gustibus et coloribus non disputandum 😄 )
then inside of my components i jus call the function
yeah i guess it is just look and feel, but to me it seems objectively simpler to understand at first glance
[:div {:style {:font-size “22px”}} “hello”] vs (dom/div #js {:style #js {:fontSize “22px”}} “hello”)
thats why I was thinking about maybe making a macro so i could just write (dom/div {:style {:font-size “22px”}} “hello”) and it just expands out
yeah that seems like a good idea
that way everything will automatically be unique due to how idents work so i wont have to think about it
And sometimes single things become many - that's what I've found anyway - just have constant numbers for the single ones.
Do you guys/girls know of any good way to have google search engine index an om.next based website. So that all the important subpages will be shown in search results? I know that google robots can't process javascript, but Im getting too carried away in isomorphic javascript, but it sounds so complicated for what seems a simple problem.
@hlolli: you can achieve that with server-side rendering
if you're using CLJS / Javascript on the server, you can use React's React.DOM.renderToString
if you're using Clojure on the backend, I just announced Cellophane yesterday