Fork me on GitHub
#om
<
2016-03-17
>
tony.kay00:03:30

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.kay00:03:02

future announcements will be on the #C0PULSD25 channel.

jlongster00:03:28

@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

seanirby01:03:05

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?

cjmurphy01:03:39

@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.

seanirby01:03:54

cjmurphy: ok good to know. any idea why Om can't pick up on the idents needed for normalization through the non-aligning query?

tawus01:03:00

@seanirby: You can have custom queries just for normalization using defui with no render implementation. May be that can help.

cjmurphy01:03:27

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.

seanirby01:03:32

tawus: yeah thats what I'm doing now, it just feels icky

cjmurphy01:03:01

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.

tony.kay01:03:03

@jlongster: Well, it is intended to be a promotional thing, with follow-up videos that address each area in detail.

seanirby01:03:37

cjmurphy: I remember you showing me that. I should probably go ahead and install it 😛

cjmurphy01:03:38

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.

jlongster02:03:22

@tony.kay: yeah, true. congrats on the release!

tomjack02:03:00

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]}]

tomjack02:03:24

not sure which is buggy, but one of them is, right? simple_smile

tawus08:03:06

Do union queries map to datomic pull syntax ?

dnolen13:03:55

quite a few things don’t - completely matching datomic pull syntax was never a goal

dnolen13:03:03

it’s just not expressive enough

tawus13:03:51

@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!

anmonteiro13:03:17

@dnolen: I think what @tomjack posted wrt. query-template is a bug

anmonteiro13:03:28

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]}]

anmonteiro13:03:34

the first case

anmonteiro13:03:01

we should be eliding the :union bit as we do in union queries without params

anmonteiro13:03:48

I've got a fix ready to PR once you confirm my suspicion

anmonteiro14:03:41

Pretty sure this is a bug after having read the query-template union tests

doddenino17:03:14

I'm a bit confused by om/Ident. All the examples I'm trying seems to work fine even if I omit it

ethangracer17:03:42

@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

doddenino17:03:41

@ethangracer: so if my data is already normalized in the right format I don't need it, right?

ethangracer17:03:00

@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!

doddenino18:03:23

I see. I think I'll have to study more that wiki article you linked. Thanks a lot for the help

adamkowalski18:03:52

is there a way to use hiccup style syntax with om next?

adamkowalski18:03:01

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

matthavener18:03:16

adamkowalski: sablano is what you want

matthavener18:03:14

[sablono.core :as html :refer-macros [html]]
and then
(render [this] (html [:div.somestyle “blah blah”]))

adamkowalski18:03:28

awesome, thank you

adamkowalski18:03:19

I think I looked into sablono before but i was having an issue with multiple children needing a unique key

adamkowalski18:03:25

how do you show a new component for each item in an array properly so that it doesn’t have the problem?

adamkowalski18:03:06

I see, so you just add the key meta data to each child

adamkowalski18:03:33

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?

cjmurphy18:03:15

@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.

adamkowalski19:03:07

ok cool, thanks for all the advice.

cjmurphy19:03:43

Not that I've tried sablono with ON, so I can't be 100%.

adamkowalski19:03:57

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

cjmurphy19:03:24

Yes there's a SO for that, give me a sec..

adamkowalski19:03:31

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

cjmurphy19:03:58

Hmm - why not just use the :id that every component has?

cjmurphy19:03:40

I know they have things like :name in the tutorials, but in real life you can use :id for everything??

adamkowalski19:03:13

fair enough, I think the reason I was having that issue is because I don’t create a component for everything

cjmurphy19:03:24

Always have an :id - and that is what the ident method uses.

adamkowalski19:03:32

if all it does is render, I just create a function which takes in data and returns virtual dom elements

iwankaramazow19:03:40

@adamkowalski: syntax is only syntax, des gouts et des couleurs on ne dispute pas (de gustibus et coloribus non disputandum 😄 )

adamkowalski19:03:42

then inside of my components i jus call the function

cjmurphy19:03:20

tastes and colours don't matter.

cjmurphy19:03:53

look and feel?

adamkowalski19:03:19

yeah i guess it is just look and feel, but to me it seems objectively simpler to understand at first glance

cjmurphy19:03:47

If you have many - you need idents - I reckon.

adamkowalski19:03:47

[:div {:style {:font-size “22px”}} “hello”] vs (dom/div #js {:style #js {:fontSize “22px”}} “hello”)

adamkowalski19:03:54

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

cjmurphy19:03:58

sablono is better I think, but regardless idents will save pain...

adamkowalski19:03:19

yeah that seems like a good idea

adamkowalski19:03:45

that way everything will automatically be unique due to how idents work so i wont have to think about it

cjmurphy19:03:51

And sometimes single things become many - that's what I've found anyway - just have constant numbers for the single ones.

hlolli21:03:04

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.

anmonteiro22:03:52

@hlolli: you can achieve that with server-side rendering

anmonteiro22:03:42

if you're using CLJS / Javascript on the server, you can use React's React.DOM.renderToString

anmonteiro22:03:17

if you're using Clojure on the backend, I just announced Cellophane yesterday

hlolli23:03:28

sorry I deleted my previous post, I misunderstood the two. Didn't know what DOM.renderToString does. Im using cljs front-end and jetty for backend. So I think DOM.renderToString will do the trick.