Fork me on GitHub

On the 0.8.0-alpha1, I'm seeing: (Might be an error I'm making, but I'm starting to doubt that.)


(That is when an event handler fires).


Any other helpful info I can extract?


Hmm. js/ReactDom is missing


My testing of alpha1 has been limited to making sure the two examples work.


I don't really have a code example because still trying to reason through it, but I'm hitting a bit of a wall in having a component that depends on the response to an ajax POST request. Say, something like a form submission--where I want the component to pick up its own error state, etc. I'm just not sure how things should be structured to pick up the response in a clean way. Does anyone have any ideas on how to approach this?


Anyone successfully integrated DataScript into their re-frame project? I was reading and looks like I can use Posh to integrate DataScript into re-frame.


@kgzm: look through the re-frame Wiki


@mikethompson: I've given the whole thing a read. It seems like the blessed solution in cases like this is to make a specific handler that will do the ajax request and put the result at some previously agreed upon location, paired with a subscription to that location. I was hoping for something a little more general and robust.


Do you know of any open source codebase with a lot of server communication? I'm curious how other people approach this with re-frame.


@kgzm: that's the way. subscriptions deliver data to views re-frame is very event driven. So responses like "failed" or "suceeded" become events and should be processed by a handler (and possibly put data into app-db) What aspect worries you?


Open source app: Don't know how much server work it does


@mikethompson: Mostly redispatching in the event handler. Since it turns into event handlers for both submit and then post-submission which handles the response, and I need some kind of unique id shared between the subscription and the event handlers to scope everything. I guess I'm worried about it eventually getting away from me.


Checking to see if we are on the same page: so you'll need an event for 1. doing the HTTP GET 2. one for processing on-success 3. one for processing on-failure


Oh wait. I see now that you are talking about a "unique id shared" between subscription and events. Hmm.


Isn't there a natural id for what is being requested?


You must be getting gif "43" or user "adamsmith"


So you'd be putting the response data into app-db based on that id?


I'm collapsing 2 and 3 and just dealing with that in a single handler. Yeah, I think there is a natural id. In terms of resource id + action. This is more for POST requests.


Okay. I think I have it. The API I'm working against is a CQRS API with named commands and all the meat in the body of a post request. So.. I can generalize this with a generic command event, some command name and body. It adds the attempted command to the db... and dispatches a post-command event.. which adds the response to an event log, and possibly uses something like a multimethod to handle specific responses. In my component as long as I can use an id or add some other scope information, I'd use that as a parameter on the command event, but it wouldn't particularly care what it is. It'd just be used to filter in my subscription handler.. I usually only care about the most recent event anyway.


Stoked about 0.8.0 showing that re-frame is still under heavy development! Explaining the architectural thoughts and concepts as done in is in my opinion what makes re-frame stand out as a clojurescript framework. Guiding me to work with architecturally sane constructs while not being constricted as with Rails is truly great! Well done guys!


What are the reasons for alpha btw? Aching to try it out 😉


@vikeri: what prevents you from using an alpha? 😄


@martinklepsch: I did a project with hyped once. It was very alpha and it sucked very much 😝 I did not realize how much it sucked until it was too late though...


right but initial release alpha and incremental release alpha are two different pairs of shoes


I have used a lot of "released" projects that were of much worse quality


I think an important part of why I'd trust to use e.g. re-frame is that it's small


it's easy enough to adopt should its development cease


of course web apps are developing fast so I don't expect any app to live more than a few years


re-frame is however close to a reasonable core abstraction that does not change often


@martinklepsch: True, just curious what the alpha mark means.


@vikeri: an alpha happened because @richiardiandrea wanted to use the def-sub stuff immediately and didn't want to wait. So I cut him an alpha. The next alpha will contain the effects/coeffects feature.


I've just spent too long trying to understand redux-saga (it gets big wraps in the effects area). Man, its hard to keep up with javascript these days. ES6 is just a completely different language from what passed as javascript two years ago.


Haha yeah, all these arrows!


@mikethompson: one thing with regards to the effects stuff: wouldn't it be cleaner to have a key like :effects in context that has a vector of maps describing effects? this way the effect descriptions are complete on their own and don't rely on data in a parent datastructure


And none of it is Googleable. I saw this: const { blah } = func() I had no idea what was going on (turns out it was destructuring) but I had no way to google for it. None of it is hard, but it feels like you are running in mud. "This is just javascript, I can read that" ... Wrong!


Haha, ran into the exact same issue in React Native. But hey, we know the pleasure of destructuring.


@martinklepsch: if I understand you ... so you are saying ... given this event handler ....

    (fn [context v] 


... the XXX bit should be {:effects YYYY }


Where YYYY is a vector of maps, one for each effect ?


right, instead of {event-type ev-description} in top-level context


Eg: YYYY might be

[   {:db  (assoc (:db context)  :var  4) }
    {:dispatch  [:some :thing] } ]


it's an implementation detail admittedly


a handler would return a context map like:

{:db new-db-val
 :effects [{:type :http/get ...} {:type :dispatch ...}]}


is the mutation of db considered an effect?


The effect is reset! app-db


Interesting idea.


The advantage of a vector is that it supplies ordering.


An ordering in which side effects should be processed.


ah ok, in that context things look different, I didn't understand it like that initially but it makes perfect sense to model db mutation as effect as well


I;ve wondered about ordering, but ended up going for the simplest approach and saying you couldn;t order effects. They are independent.


Some effects might assume already updated db?


I thought it was probably the other way around. Some effects might themselves want to update the value of :db BEFORE the :db effect


But I think it all gets too complicated.


I look at these things through the lens of writing the docs. If it is hard to explain, I don't want to do it 🙂


Which is kinda why I ended up thinking that effects could not influence each other. Independent.


But I kinda like you idea as a fall back


@mikethompson: what other event systems have you looked at researching this btw?


So I'm now wondering if YYYY (see above) can be either a map or a vector of pairs. And if it is a vector then effects will be processed in the order given


redux-saga and Elm . Plus languages like Eff. Plus the recent effects and coeffects stuff from Tomas Petricek. Some other stuff, can't remember


I'm wondering if the unorderedness couldn't lead to unexpected behavior/failure? potentially non-deterministic?


or are maps ordered in some way as well?


In general, I can't see it. But it has been on my mind. Which is why I like the idea of supporting it via a vector


In general the vector format is a bit clumsy. But it might act as a fall back for when you care about ordering.


just came to mind: multiple effects of the same type? e.g. two http requests, is that something the effect handler should take care of?


If you're still curious about other approaches: I found this interesting:


BTW, when investigating effects, I wanted to get some experience of them before fixing on anything, so I designed an async flow. Here is the emerging effect:


no code, just readme 🙂


Wait on. Let me update that readme, it is old now


Updated. Actually in retrospect, maybe reading that is a not that useful.


@martinklepsch: is there a document around describing uxbox. I feel I need some context for the code.


Ahh, so it is using a wrapper for bacon.


@mikethompson: it's a project under active development so I couldn't find much docs. @niwinz in #C093UFM4M is probably happy to answer some questions but just to give some context: they separate UpdateEvents (= pure handlers), WatchEvents ( = effect handlers eventually emitting UpdateEvents), and Effects (= effect only). I found the idea of WatchEvents interesting but maybe it is a bit to specific to the RX stuff they're using


Also just generally the protocol approach seemed interesting, but that's a different thing entirely


...checking the rstore.cljs file above... combinators are kind of neat to have in re-frame


the classic example is to combine multiple results of effectful functions easily


I saw the and in Mike's document and it is cool that we added that (and being :seen-all-of)


wouldn't be cool to be able to use clojure functions in :rules? Maybe it is already possible with the current WIP design