Fork me on GitHub

Subscriptions are a pretty new feature of graphql which isn't necessarily supported by all implementations yet


But you can definitely use GraphQL without subscriptions


what's the idiomatic way now in re-frame to update the DOM; eg after a successful form submission, if I wanted to clear input fields that remain rendered?


(reg-event-fx ::send-form [{:keys [db]} [_ foo bar] {:http-event [{:http-params [foo bar] :on-success ::succes-send}]}) (reg-event-db ::success-send [db [_ response]] (-> db (dissoc :form/foo :form/bar) (assoc :form/response response)) @pandeiro


@souenzzo So you're using :value in the inputs not :default-value, to simulate two-way data binding?


Not sure if I understand, but on this example, the form fields should be on :form/foo/`:form/bar`


Sorry, I was referring to the hypothetical [:input ...] components


They would be subscribing to :form/foo and dereferencing that in the component's :value attribute, I imagine


Yep, should be one subscribe for each input. And an event on each on-change. You probably want to use dispatch-sync on this events.


I have a single event (reg-event-db (fn [db [_ k v]] (assoc-in db [:form k] v))) and a single sub (reg-sub :form (fn [db [_ k]] (get-in db [:form k])). But not sure if it is a "best practice"


Then on input I have [:input {:value @(subscribe [:form :some-key]) :on-change #(dispatch-sync [:form :some-key])}]


Hi, we have a larger re-frame app and a smaller app (mostly a single page view, but complex) that we’d like to merge into the larger app. I’ve been looking at the structure suggested and that makes sense to me.


The smaller re-frame app components will not appear be in the same panels or views as those from the larger app, although it will be in the same codebase and share the same back-end infrastructure. The smaller re-frame app is relatively independent. I also assume that there will be a single compilation unit (e.g. app.js) which will contain a core namespace that will init both re-frame apps.


So my question is, would there be any benefit for sharing a single DB, or having access to shared events? I can’t think of a reason why this would be useful in my case, but may be missing something. Sharing a DB would make our integration work harder, possibly because we’d have to change the DB paths used by reg-event-db, which means making breaking changes (mistakes!) to the smaller app that is already working and having to debug that.


Has anybody else done this?


@scottlowe do all your events / subs / db keys use fully-qualified keywords? Merging 2 re-frame code-bases will make them share the same db and event/sub registry (since those exists in the re-frame namespaces) so if you already use fully qualified keywords then there will be no problems at all~


If you're not using fully-qualified keywords when you'll probably have to use 2 dbs and registries which is kinda not-so-trivial to implement....


In fact, I have no idea how you'd go about separating the event/sub registry besides re-implementing reg-xxxx yourself.


Hello. Is there any pattern for following task: re-frame app. There's a model dialog which dispatches async event and i'd like to close the window when response is received. I suppose passing callback is a bad idea. So should i kinda track request status inside modal dialog and close window when it finishes inside component-did-update or render? Currently i'm doing request-response outside re-frame and just put results in app-db but i anticipate there's a more idiomatic way


@akiroz The events events / subs / db don’t use fully-qualified keywords at present, however we are planning to do that. Thanks for the warning, that’s answered my question and I’m glad I asked it. Shared DB it is, then. I haven’t looked at the re-frame internals, so knowing that it’s “not-so-trivial to implement” is really worthwhile information, and very much appreciated. Bullet-dodged. Thanks!


@nidu the idiomatic way would probably be to have: - an event that initiates the async request via a fx - an fx that will dispatch another event when it receives the response - that event could either set some kind of show-modal? key in your app-db to false directly or dispatch another event for closing the modal