This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-09
Channels
- # beginners (55)
- # boot (173)
- # clara (3)
- # cljs-dev (10)
- # cljsjs (3)
- # clojars (11)
- # clojure (110)
- # clojure-austin (5)
- # clojure-berlin (13)
- # clojure-chicago (2)
- # clojure-dusseldorf (3)
- # clojure-france (24)
- # clojure-italy (4)
- # clojure-portugal (1)
- # clojure-russia (60)
- # clojure-serbia (8)
- # clojure-spec (150)
- # clojure-uk (129)
- # clojurescript (87)
- # core-logic (1)
- # cursive (75)
- # datavis (1)
- # datomic (75)
- # devcards (4)
- # dirac (17)
- # emacs (50)
- # events (2)
- # hoplon (9)
- # jobs (4)
- # jobs-discuss (37)
- # lein-figwheel (3)
- # luminus (5)
- # off-topic (54)
- # om (9)
- # om-next (5)
- # onyx (10)
- # perun (11)
- # protorepl (11)
- # quil (2)
- # rdf (2)
- # re-frame (14)
- # reagent (58)
- # ring (13)
- # ring-swagger (10)
- # rum (52)
- # spacemacs (8)
- # test-check (10)
- # untangled (17)
- # yada (34)
@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..."])))
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
hmm yeah actually i don’t have a good answer
I thought it was cleaner, but now i think it’s not
thanks 🙂
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
Did anyone try the reconciling approach of om.next with rum?
@misha Thanks, much better now. Solved also another problem. I guess I don’t need to know about child-contexts
anymore 🙂
@jeroenvandijk can you describe what reconciler does, or what you want to solve with it?
I’ve published a gist just now https://gist.github.com/jeroenvandijk/9cbf0048cd87f5c416ee8cab9c52ecb7
I want to have what om.next has, but than in a simple such as in rum
i want to decouple the ui from the data part
haha yeah, but if you see the gist i think you'll understand what it could do
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
yep, thanks to rum 🙂
it’s mostly copied from rum.core/reactive
I mean "I'd prefer 2 sentences describing intent in english, rather than dive into 100 locs of implementation"
ah o 😞 haha
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
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
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
it can get messy with lots of arguments, but then you have an option to wrap them with a {} or a record
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
referencing to reconciler inside a component is absolutely the same, as referencing an atom
yes true, this is just the start of creating the parsing thing of om.next
you don't have it in args, therefore you need to rebind it during testing - same level of hustle and (in)convenience
yeah maybe
Do you see the advantage of om.next?
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
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
That’s the thing I’ll copy/steal and combine with this to make it work 🙂
(fingers crossed)
thanks for being skeptical. I’ll have to proof i’m right
that’s true, but it helps me to make sure I’m working on something useful
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
Do you have an example of how you deal with asynchronous calls?
From a rum component i mean. I wonder how it is different from what i’m trying to do
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
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)
ah yeah, sounds like the right approach
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@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
@jeroenvandijk what are you trying to accomplish currently? I'm getting my feet wet with om next..