This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-25
Channels
- # beginners (27)
- # boot (49)
- # cider (51)
- # cljs-dev (29)
- # cljsjs (1)
- # cljsrn (19)
- # clojure (59)
- # clojure-austin (2)
- # clojure-belgium (19)
- # clojure-china (1)
- # clojure-dev (14)
- # clojure-dusseldorf (7)
- # clojure-russia (8)
- # clojure-spec (115)
- # clojure-uk (45)
- # clojurescript (118)
- # css (6)
- # cursive (8)
- # datascript (20)
- # datomic (32)
- # emacs (5)
- # events (2)
- # flambo (21)
- # hoplon (58)
- # incanter (8)
- # jobs-rus (1)
- # jobs_rus (1)
- # off-topic (3)
- # om (22)
- # om-next (9)
- # onyx (5)
- # other-languages (79)
- # re-frame (126)
- # reagent (6)
- # ring (7)
- # specter (1)
- # untangled (119)
- # yada (38)
@mvaline: the component is literally what I posted:
(defn exec-scripts [scripts]
[:div
(map (fn [s]
[:script {:dangerouslySetInnerHTML {:__html s}}])
scripts)])
and each script is something like function () { part that should execute... }();
@sbmitchell: thanks for the snippet example! 🙂 I'm not loading an external file though, just trying to execute some js on the spot
At this point I think it's wiser to rewrite all those little things in cljs...
@superstructor: don't tie yourself to core.async if you don't have to
my recommendation is to start with a simple base (perhaps cljs-ajax? it's nice and works great for us)
@nilrecurring: you can probably inject the script tag into the html head manually
@superstructor: I second the suggestion of pesterhazy on cljs-ajax, works great in all my projects 🙂
@pesterhazy: something like creating the new element with (js/document.createElement "script")
and then (js/document.head.appendChild new-script)
I guess that would work
But already rewriting the things in cljs, I figured out that in js they would be unmantainable anyways 🙂
sure that sounds great too
when I swap the model of a datepicker comp to another month, the ui stay on the same month
Maybe youll get more hits #C0620C0C8 but I suppose most people here in re-frame are using reagent and possibly re-com 😛
Has anyone done anything with generative testing just using re-frame handlers to validate a workflow thru each step?
Ex. I have a login page with its own handlers for auth, logout, and form fields. It would be interesting to generate a test by setting up workflows as a tree data structure of handlers which you could like run a tree-seq on to evaulate all paths of a workflow
this is without interaction with the dom of course
I have a burning secret: I don't understand Reagent at all (and yet use re-frame a lot)… 😞
I think reagent is the easier wrapper of react to understand 😛 you just write functions
easiest*
lifecycles are probably required for more interesting stuff but for the most part its just writing functions heh
and you dont need to understand virtual dom loveliness though that stuff is quite interesting to read about
@fasiha: I'm kind of at the same place - Reagent is just too easy to use, but I end up having to go back and re-read the basics when I run into problems. Planning to do a toy re-implementation of re-frame in Rum at some point to force myself to get a better understanding of how things work without all the magic.
yea the reaction / ratom stuff is pretty magical
@fasiha: I used re-frame for 1y before actually having to understand all the components lifecycle thing
Everything is pretty magical and just works
In reagent, instead of subs/handlers, each "view" (react component) contains its own state and manually hands off pieces of it to children?
That is the essence of good abstractions
I still need to digest the react docs on lifecycles, I haven't run into a situation which drove me to read that section
@nilrecurring: Totally. re-frame and reagent is one of the abstractions that just seems to work without having to think about it, pretty nice compared to a lot of other things.
I spent the last 3 months on a re-frame app and shipped it today for Real Work (first experience with cljs/react/etc.)
@fasiha: Congratulations! Is it public facing?
@shaun-mahood: alas, no
I've found re-frame to be relatively easy to refactor as bugs are found etc., so don't worry too much
@fasiha: congrats! I feel you, all my cljs stuff is not public facing as well 😞 I love how lifecycles are described in the re-frame wiki: " While you'll ignore Form-3 components most of the time, when you do need them, you need them bad."
@shaun-mahood: absolutely
I actually use form-3 components majority of the time now to be honest
especially for anything that needs to be composable and actionable from a parent. In the externally controlled component scenario you always need a state update from component-will-receive-props
to update the internal state of the child component
@sbmitchell: i think i tend to use form-2 with a state r/atom updated in the inner render function for state updates... what's the advantage to form-3 there ?
you put state change calls inside the render fn? wouldnt you then need terminating conditions wrapping every state change
if Im using form-3 I find having the state external in a let binding is a lot more clear as far as what its closing over
I think a lot of it is just preference
there was something about the closures that @mikethompson had brought up in a previous discussion here
oh you are saying (let [state (r/atom val)] (fn [])
was confusing that with using with-meta
the only advantage of form-3 is that you can add lifecycles at that point
like I said...when you have a "toolkit" of components that may need to have internal state + have external control like for form components where you really want to be able to control state from the outside
you will need form-3 to handle the lifecycles better
yeah, that's true... toolkit components often seem to need lifecycles
yea thats kind of what I was referring too mostly
plus pretty much anything that is a container component will need them too...
so then I end up with 90% of components using form-3
I suppose there is an equivalent way to do with form-2 style
passing in the atom etc
but I prefer to only pass in simple data structures into components at all times..so always derefed or have it avail from within the closure
There is also the fact that to trigger fetches for re-frame I dispatch inside of component-did-mount
to load a particular field of interest that the comp would subscribe too
hmm... i don't think i pass in atoms anywhere, though i do pass in an occasional function into some components... and i do have a pubsub thing for some bus-style comms
well there is no way around not passing fns around..I think some of the older reagent examples passed down atoms
that you would then reset inside of the child
but I prefer it have it go 1 way
like react wants it to be
if i'm doing a form-3 i'll use component-did-mount for fetches, but otherwise in a form-2 i'll just put the fetch before the inner render fn in the form-2 closure
yea but what if its not a 1 time fetch
then you may need to do it in component-did-update as well
not sure how form-2 works with that
does it re-init the component
yeah, that wouldn't work with form-2
you can probably get around component-did-update by starting a "subscription" (not re-frame sub) but an actual backend sub w/ websockets or something that would push data into the field you were initially intersted from the original fetch
then its a single call and reactions come from the generated subscription in the future
thats a pattern I was intersted in trying in my current app
that would require a full push model of course
i do have updates from the backend - i use a websocket with a go-block which dispatches to re-frame handlers and then that flows to reagent components via re-frame subs
so you basically have 2 event loops running the entire app?
one form re-frame to do event handlers
then one to dispatch to more handlers?
that you run
yes, you can look at it like that
Interesting
how has that worked for scale
scale on the UI ?
or are you meaning elsewhere ?
as far as the events
Im trying to imagine how your own dispatcher knows what dispatch calls to make
do you wrap all fetch handlers to a registry
this is helping me btw thanks 😉 I need to implement something very similar in flow like now 😛
oh, it's pretty simple... there will be a registry when i get around to it - there's just a big core.match pattern-match atm
ahh core.match
seems like it would be pretty simple to just have a simple hash-map cache for the registry
subscription-topic -> vector of registry handlers perhaps
each fetch handler could have middleware to insert into the registry and start the sub or something
will ponder some more 🙂 thanks
yeah, i put [tag, val]
records onto the websocket, and you can dispatch on the received tag
easily with a map-registry
and then do whatever you like with the val
have you done any workflow testing that way using only the event handlers
so like given a tree structure of events -> do a depth first traversal to do handler mutations -> compare end db to expected
no 🙂
obviously one off handler tests are nice but I want to try some sort of generative pattern
so I can just define them as a data structure to run 😛
yeah, that would be nice
seems very possible as long as everything runs thru the centralized store
@mccraigmccraig @sbmitchell following your interesting discussion my mind went wondering: is there anything in cljs to do pubsub over websockets?
like: event with some key comes -> gets dispatched on a handler
@nilrecurring: are you thinking of a cljs client subscribing to a bunch of topics via a websocket ?
@mccraigmccraig: yep. It's fairly easy to roll your own, since it's just agreeing on a protocol with the server and then keeping a hashmap with the handlers mapped, and having a dispatch function
yea my company rolled their own
I did not write that particular section of the code but basiaclly it follows how MDN describes how to interface into websockets
using pings etc to keep it alive
i do it with gnatsd on the backend
and then there is transit
then we have compojure routes that are just on /ws and the cmd are dispatched to our api fns
yea, I usually roll my own too
But it would be nice to have everything already implemented. I didn't actually used sente, but it seems that it doesn't have a pubsub
I have not personally used it so I cant comment
there was a cool video where the author made a multi-user snake game though
@nilrecurring: gnatsd and my very own https://github.com/employeerepublic/clj-nats-async do very nicely for pubsub on the backend... then it's trivial to wire up to your client via a websocket with aleph and manifold
@mccraigmccraig: oh nice thanks!
thanks for all the advice re http lib, I’ll give cljs-ajax
a try @pesterhazy @nilrecurring @mikethompson @sbmitchell