Fork me on GitHub
#re-frame
<
2017-01-26
>
kishanov05:01:56

on a scale from 1 to 10, how bad is the idea of storing Reagent components inside app-db? (1 - not so bad, 10 - worst idea ever)

akiroz06:01:14

are we talking about reagent components (pure functions) or the reified element (DOM element)?

kishanov06:01:59

pure’ish functions. I’m not sure that Reagent component that subscribes to some data via re-frame internally satisfies the definition of “pure"

akiroz06:01:08

I'd generally avoid both, clojure functions are compiled and if you print the app-db you'll see a huge JS blob lol

akiroz06:01:49

what are you trying to do though?

kishanov06:01:56

how about storing a view function name instead of a whole function and use some magic to render a component based on it’s name?

akiroz06:01:37

^ that's what most of us do in practice

akiroz06:01:27

you can create a view using a multimethod and dispatch based on the view name

akiroz06:01:51

or just have a case block

kishanov06:01:53

I’m trying to find an alternative solution to exactly that 🙂

kishanov06:01:18

I kinda like a solution when as a result of routing dispatch I can store some :active-panel key inside db, but I don’t like the fact that resolution of what should be rendered happens on a view level (via multimethods or case)

kishanov06:01:25

the reason for it is that when my active-panel component is more complex then just current view (i.e. imagine a layout which has breadcrumbs, active view title, primary action/main menu for a current view, active panel itself) each of these components should have some kind of map between active-panel key and what should be rendered

akiroz06:01:51

right, I currently have all my main views contain a header component that subscribes to :active-panel but I'd love to see if there are better solutions too~

kishanov06:01:26

the solution that I’m trying to scribble is some kind of a map which maps route key to a pre-defined map of multiple things: let’s say title, API calls that should be made, views that should be rendered, list of containers for views that should be used as interceptors in order to make sure that make sure that result of all api calls is 200, data has been saved to db, etc.

kishanov06:01:45

in other terms, I want to create some kind of a sitemap datastructure, that maps route to everything which can be a result of this route (i.e. views rendered, data fetched, etc.) and reuse this sitemap to make decisions about redirects, POST API calls that should be done, etc.

kishanov06:01:39

if this kind of data structure is flexible enough most of the processing logic can be simplified to map lookup

akiroz06:01:05

that sounds interesting, do keep us updated~ 🙂 maybe it could even help pull in the right modules at compile-time...

qqq11:01:41

does re-com have a 'table' element?

qqq11:01:48

if not, how are the "parameters" table being displayed?

owen16:01:32

has anyone found a good solution to query duplication as a a result of following the "Subscribe to an external datasource" pattern? This is described as the following sub (excuse pseudo-code)

(reg-sub
  :people
  (fn [{people :people :as db] _]
    (make-xhr-request-for-people)
    people)
Where make-xhr-request-for-people queries an API and puts the results into the db at :people? I've solved it previously by only running that fn if -> db :people :loading is false/`nil` and setting it to be true in make-xhr-request-for-people. I feel it could be done better with query de-duplication / memoization... curious if anyone has a pattern for this they like

ckirkendall18:01:20

that will create a constant loop

ckirkendall18:01:19

calls out to xhr should be reserved for handlers.

ckirkendall18:01:33

what are you trying to do with this?

owen18:01:08

? that is listed in the re-frame docs as a good way to subscribe to external data

owen18:01:17

it works

owen18:01:51

without query de-duplication it will make 2 http requests

owen18:01:54

when the db input changes

owen18:01:00

but you can prevent that

owen18:01:08

by checking for a :loading key or some such

owen18:01:17

IM curious if people have done it without polluting the db

owen18:01:27

via memoization or some other approach

ckirkendall18:01:32

can you link to the where in the re-frame docs it suggests this.

ckirkendall18:01:44

This kind of goes against the whole idea of pure functions for subs and ahndlers

owen18:01:59

I know we're all pure fn purists 🙂 but at some point you need some external input 🙂

ckirkendall18:01:51

yeah but you can isolate that in an http interceptor. https://github.com/Day8/re-frame-http-fx

ckirkendall18:01:15

also the example in the docs shows using reg-sub-raw that returns a reaction

ckirkendall18:01:31

that way it only runs the let binding once.

ckirkendall18:01:38

so the query only runs once.

owen18:01:02

hmm interesting, I haven't tried that, I've been using this approach since before the big change in .0.9 which I believe might not have had the reg-sub-raw form

owen18:01:07

that could be the solution

spieden18:01:18

i think reg-sub-raw is the old behavior

spieden18:01:47

effects handlers are great, although i ended up needing to write my own http one based on a different client lib

owen18:01:08

I think your right about that

ckirkendall18:01:23

you use reg-sub-raw here because you only want the query to run when the subscription is created.

owen18:01:41

yeah that would work well I believe

owen18:01:23

yeah the old register-sub

owen18:01:36

(register-sub
 :sorted-items      ;; the query id  (the name of the query)
 (fn [db [_]]       ;; the handler for the subscription
   (reaction
      ...

owen18:01:45

you could also wrap the reaction in a let

owen18:01:48

cool, thanks guys