Fork me on GitHub
#rum
<
2017-02-09
>
Niki06:02:08

@sova something like that:

(defn ajax-mixin [url key]
  { :will-mount
    (fn [state]
      (let [*data (atom nil)
            comp  (:rum/react-component state)]
        (ajax/get! url (fn [data]
                         (reset! *data data)
                         (rum/request-render comp)))
        (assoc state key *data))) })

(rum/defcs comp < (ajax-mixin "/api/data" ::data)
  [state]
  (let [*data (::data state)
        data  @*data]
    (if (some? data)
      ...
      [:div "Loading..."])))

jeroenvandijk14:02:04

Btw, I’m trying to build something like the reconciler in om.next for Rum. Anyone tried this before? Maybe I’m being naive, but so far it seems doable. I will steal the parser part of om.next itself. Maybe i’m ignoring all the efficiencies om.next has

misha15:02:31

why this instead of explicit arguments?

jeroenvandijk15:02:40

hmm yeah actually i don’t have a good answer

jeroenvandijk15:02:08

I thought it was cleaner, but now i think it’s not

jeroenvandijk15:02:46

I was approaching it the same way as how the reactive mixin works and that doesn’t have arguments. But i think with some trickery i can use that same approach while having arguments

jeroenvandijk15:02:07

Did anyone try the reconciling approach of om.next with rum?

jeroenvandijk16:02:10

@misha Thanks, much better now. Solved also another problem. I guess I don’t need to know about child-contexts anymore 🙂

misha16:02:19

@jeroenvandijk can you describe what reconciler does, or what you want to solve with it?

jeroenvandijk16:02:14

I want to have what om.next has, but than in a simple such as in rum

jeroenvandijk16:02:31

i want to decouple the ui from the data part

misha16:02:38

(macroexpand 'what-om.next-has)

jeroenvandijk16:02:07

haha yeah, but if you see the gist i think you'll understand what it could do

misha16:02:15

100 lines! harold

jeroenvandijk16:02:17

we have a pretty complete rum application and I found it hard to work with cursors and “services” that can provide data. I think om.next has a better approach for it, but i don’t want to use om.next

jeroenvandijk16:02:24

yep, thanks to rum 🙂

jeroenvandijk16:02:46

it’s mostly copied from rum.core/reactive

misha16:02:29

I mean "I'd prefer 2 sentences describing intent in english, rather than dive into 100 locs of implementation"

jeroenvandijk16:02:59

ah o 😞 haha

jeroenvandijk16:02:10

so with our current rum application I have to manage data from with the UI components and that complicates things. I think the query model of om.next makes life easier

jeroenvandijk16:02:46

This is a really simplified approach to what om.next does. So it will probably fail to do some of the magic. It needs some testing

misha16:02:59

in my project I went with: - huge atom (you can cover it with spec) - ns with getters/setters - dumb (pure) components, accepting fetched data - smarter components, fetching/modifying data and passing it to dumb ones

misha16:02:06

it can get messy with lots of arguments, but then you have an option to wrap them with a {} or a record

jeroenvandijk16:02:25

yes, we had the same process. For me it is still too complicated. We started using stuart sierra’s component and that helped. However due to the asynchronous nature of http calls it still becomes messy. I hope this will make it cleaner. We’ll see

misha16:02:53

referencing to reconciler inside a component is absolutely the same, as referencing an atom

jeroenvandijk16:02:25

yes true, this is just the start of creating the parsing thing of om.next

misha16:02:03

you don't have it in args, therefore you need to rebind it during testing - same level of hustle and (in)convenience

jeroenvandijk16:02:37

Do you see the advantage of om.next?

misha16:02:47

another option is event sourcing (re-frame?)

misha16:02:29

I don't, other than "other people spent time on developing/testing it, not me" opieop

jeroenvandijk16:02:27

I believe in the concept behind it, but I really dislike the setup of the code and how the application code looks like. I prefer Rum in it’s simplicity. So I hope I can combine the two

misha16:02:50

the only interesting thing for me in om.next - is a static recursive query definitions on components. but I think it's not exactly the same thing you are trying to implement

jeroenvandijk16:02:13

That’s the thing I’ll copy/steal and combine with this to make it work 🙂

jeroenvandijk16:02:22

(fingers crossed)

jeroenvandijk16:02:23

thanks for being skeptical. I’ll have to proof i’m right

misha16:02:19

you owe nothing to anyone : )

jeroenvandijk16:02:02

that’s true, but it helps me to make sure I’m working on something useful

misha16:02:51

I try to separate components and data manipulation too, and after several iterations I end up with: data (atoms), dao ns (which can be tested and implemented w/o any UI available), and later - components. but eventually, your dao getters/setters are heavily influenced by components, making database - the only ui agnostic place in app

jeroenvandijk16:02:27

Do you have an example of how you deal with asynchronous calls?

jeroenvandijk17:02:36

From a rum component i mean. I wonder how it is different from what i’m trying to do

misha17:02:12

component calls call modifies atom atom causes component re-render

misha17:02:30

but actually it's a bit more complicated than that. in some places I keep proxy atom, which does the call, to have component optimistically updated right away

misha17:02:04

component updates proxy atom proxy atom does the async call proxy atom causes component re-render async response updates proxy atom proxy atom causes component re-render (if optimistic value is different from actual async call value)

misha17:02:56

c <-> a <-async-> call
instead of
c -> async call
^   |
|   |
a <-+ 

jeroenvandijk17:02:52

ah yeah, sounds like the right approach

jeroenvandijk18:02:14

I’m looking into the query part of om.next now. I think I do need to do something with :child-context to calculate the nesting. So if anyone has a proper alternative for

(some-> (:rum/react-component state)
                      .-_reactInternalInstance
                      (aget "_context" )
                      .-publisher))
Please let me know

sova-soars-the-sora21:02:46

@tonsky thanks a lot sir. So I can use an ajax callback on will mount and it'll pretty much do what I want... o.o awesome

sova-soars-the-sora21:02:23

@jeroenvandijk what are you trying to accomplish currently? I'm getting my feet wet with om next..