Fork me on GitHub
#om
<
2017-01-23
>
drcode01:01:15

@claudiu : Untangled is pretty great, I've watched and read all the resources Tony has put together.

drcode01:01:47

@sova: There's several different approaches around navigation, I recommend reading this if you haven't yet: https://anmonteiro.com/2016/02/routing-in-om-next-a-catalog-of-approaches/

Joe R. Smith14:01:47

@sova, nice thing about react is show/hide = render/not render to the DOM

danielstockton15:01:19

it can still be more performant changing a display property, can't it?

danielstockton15:01:21

i'd say it depends

sova-soars-the-sora19:01:56

@danielstockton display properties? mmm maybe. There are certain things I do not want to even exist in domland, like the login apparatus once someone is logged in. i'd rather not have it show up for a curious developer just because they know how to change CSS.

danielstockton19:01:26

sure, most of the time i do the same

Joe R. Smith20:01:46

react certainly encourages you to treat the DOM as just a “dumb” render target and not store any data applicable to the rendering of your app in the DOM

danielstockton20:01:34

@drcode for what it's worth, i mostly agree with the results of your poll. I never had a problem with read transacts but I would really like to use datascript (but can't, set-query!) to avoid the normalization magic.

sova-soars-the-sora20:01:39

I could use some help making my mutate function work

sova-soars-the-sora20:01:46

my app-state-atom looks like:

sova-soars-the-sora20:01:08

(def nf-app-state-atom (atom
                        {:nf   [{:blurb-content-input "starting blurb input val"
                                 :blurb-link-input "linkzes"
                                 :blurb-tag-input "tagses"}]...

sova-soars-the-sora20:01:42

my read function works splendidly, but my mutate function... does not change the atom value..

sova-soars-the-sora20:01:08

(defmethod mutate 'edit/blurb-link-input
  [{:keys [state]} _ {:keys [blurb-link-input]}]
  {:value [:get/blurb-link-input]}  ;;read function works, but the next line.. not sure what  to change
  {:action (fn [] (swap! state update-in [:nf :blurb-link-input] blurb-link-input))})

danielstockton20:01:21

@sova, :nf is not a map but a vector, you can't update-in

danielstockton20:01:05

update-in [:nf 0 :blurb-link-input] should work, 0 being the index of the vector

drcode20:01:05

@danielstockton :thumbsup: I had some ideas for how read queries could work differently to help with refreshing parent components (which is the use case where the current approach has been challenging in my experience) but I think maybe the current approach is probably still the best (still thinking about this though)

Joe R. Smith20:01:50

@sova your update-in is also missing a function

drcode20:01:49

@danielstockton As for the normalization magic, the only alternative I think is to build extra libraries with tools to make manual normalization more convenient (which I am going to experiment with)

sova-soars-the-sora20:01:04

I had all values as top level atom values :nf/blurb-link-input and had the code working, but now adding the (tree) leveling {:nf [{:blurb-link-input ..etc}]} to the atom requires a change of some kind...

sova-soars-the-sora20:01:30

So .. maybe I need a funkshun, but I had it working as is, just w/ different atom talk

sova-soars-the-sora20:01:44

adding 0 did not do the trick... but I'ma keep tinkering

Joe R. Smith20:01:41

if you want to set the value of :blurb-link-input and that map will always be in a vector, you want (swap! state update-in [:nf 0] assoc :blurb-link-input blurb-link-input)

Joe R. Smith20:01:41

update-in requires a function to apply to the current value at the keypath. If you simply want to replace the value, use assoc-in

Joe R. Smith20:01:05

e.g.: (swap! state assoc-in [:nf 0 :blurb-link-input] blurb-link-input)

sova-soars-the-sora20:01:00

Thanks. my macbook ran out of memory and lighttable lost all my work since last night so...

sova-soars-the-sora20:01:03

I'll get back to you xD

sova-soars-the-sora20:01:45

Yeah I ran out of solid state memory, and lighttable does a funny thing when you run out of memory: it clears the file you were working on. thankfully github desktop got me back to running

bostonou21:01:48

@drcode could you elaborate on your challenges with refreshing parent components? i think it might be similar to the issues i’m having

bostonou21:01:43

it seems like it would be useful to have a “parent component” that runs a query, and then the “child components” that are dumb and just take props from the parent. the parent would then update anytime any of its data changes, along with children getting shouldUpdate calls

alex-glv22:01:03

Not strictly om, but has anyone had experience with html5 drag and drop and om (or react?). I am implementing trello like moving cards feature, and once I move element to another column it of course unmounts and mounts in a different place, but then neither ondrop nor ondragend fire, because apparently removing element from dom removes the handlers as well..

alex-glv22:01:23

I implemented a hack with hiding the element and simply drawing a “shadow” element, but there’s so much hacky code that grown around it.

hlolli22:01:16

@alex-glv https://github.com/sgrove/om-draggable http://annapawlicka.com/draggable-wrapper-component-with-om-and-core-async/ some attempts to create draggable components with om, I found these attempts to be rather unsmooth, react-draggable I found to be just perfect for what I was looking to to, which was only a draggable component, but adding routing logic depending where its released is easy. Look at cljsjs/react-draggable.

anmonteiro22:01:31

@alex-glv I'm pretty sure Jannis implemented that feature in his Om Next kanban demo: https://github.com/Jannis/om-next-kanban-demo

alex-glv22:01:35

Neat! I’ll check these out, thanks