re-framers fellow re-framians :-)

@joelsanchez your words have been re-framed. 😉

@joelsanchez looks clear enough. Didn’t know you could chrome like that from clojure, might want to use it for running tests

Hey, struggling to find the terms for this, but what's the practice for "derived subscriptions?"

e.g. if (subscribe [:numbers]) gives a list of integers

can I have (subscribe [:filter even? [:numbers]])?

think it’s best to create a seperate subscription for it, because you only want to re-render when even numbers change

guess it's more of a "how many subs I feel like writing" kind of thing?

i.e., when [:numbers] change, i'm happy for all the subs to run

but feels easier to write (subscribe [:filter even? [:filter bigger-than-10? [:numbers]]]) than to write

(subscribe [:even-and-bigger-than-5]) etc.?

(assuming i've got a bunch of compossible things to filter by)

Hello re-framians, re-frame-trace 0.1.19 is out: https://github.com/Day8/re-frame-trace/releases/tag/0.1.19. There’s a big change to how subscriptions are processed which should be more accurate. Give it a spin and let us know if there are any issues. We’re finishing up work on re-frame-trace very shortly, so nows the time to get your feedback in.

@danielcompton thanks! Loaded in my project, everything seems to be working fine.

🙂

@danielcompton: you got any thoughts on derived subscriptions ⏫?

@shen a first principle for re-frame is to store everything as pure data as much as possible instead of functions. So I probably wouldn’t want to be passing functions to a subscription

If you have a bounded set of possible filters, I could imagine passing data parameters to a subscription which configures which filter transducers are run.

Can you give a bit more context to the problem you’re trying to solve?

hmm... maybe not passing fn's then

ok, numbers is probably a bad example

so, let's say we have a col of gizmos

and each has three properties, colour, shape and pattern

so, we can get the whole thing with a (subscribe [:gizmos])

and probably have a (subscribe [:gizmo-by-colour :red])

(subscribe [:gizmo-by-shape :square])

etc.

now, if i wan red squares, I'm thinking I can either have [:gizmo-by-shape-and-colour :square :red]

but this also suggests [:gizmo-by-colour-and-pattern :red :stripes] etc.

or, I can have a [:filter-by-colour :red [:filter-by-shape :square [:gizmos]]]

so I only need to write 4 subs, and at run time, these data only subs are constructed, with some code like

We have a similar kind of pattern in our code base, I’ll need to check and see what we did there. I think I’m at least one case we built up a materialised View in event handlers responding to filters changing (though that was very complicated from memory)

@shen the current colour (`:red`) will be stored in app-db somewhere, yes?

I can't see these filter terms coming our of thin air

They'll be arising because of user actions ... so they'll be in app-db ?

Anyway, ignoring that line of questioning ... back to your line of reasoning (that the view supplies the filter terms) wouldn't you just do it as something like this ... (subscribe [:gizmos {:shape :square :color :red}])

thanks

@mikethompson think I see what you are getting at. that if there's a shape dropdown, and color dropdown, then can hook it up that way?

will think through this. just wondering to what degree do I actually need composibility

By "composability" are you indicating that you might want "many"

i.e. many components each asking for their own list of gizmos, using their own (local) set of filters?

so, let's say we have three properties

as above

so 2^3 possibly types of components: i.e.

everything, filter by color, filter by color and shape etc.

(3 being larger in real life)

so, it's a "how many (types) of subscriptions do I need question"

but I do see that your solution says you can do it with one

So "many" of these components can be on-screen at once ... is that the challenge?

less on screen at once. more just amount of boiler-platy code

oh right. you mean more types on-screen means more subs in memory, right?

Not really

I'm just trying to understand the challenge

When you say 2^3 possibly types of components then you mean there can be one component on the screen which can be in any one of 8 configurations?

And by "configurations" we mean "configurations of filters"

no. meant something a bit different

so, first question: the challenge is less in terms of performance/number of subs etc.

really started with me trying to not write [:gizmo-by-color :red]

which your suggestion of [:gizmo {:colour :red}] does solve

I'm finding it hard to see any variation of this that involves more than one subscription (although if you want what I call the "many" arrangement, you might need multiple "instances" of this one subscription)

think you are right.

but thanks. think I was trying to do something a bit weird

appreciate the help

no problem

appreciate all the work and help, btw 🙂

@shen, this might not be helpful to you, but we put together https://github.com/riverford/compound for the case when you have things (e.g. gizmos) that you might want to filter or index by multiple things (e.g. by colour or shape). The materialized indexes are built as you put data into the db.

oh cool. will have a look

thanks @danieleneal

what this may mean [:> ] ?

it's for interop I think

totally impossible to search for :s

but something akin to reagent's adapt-react-class

@faxa @danieleneal It's described here: https://reagent-project.github.io/news/news060-alpha.html

Fixed.

nice!

When I have several events which change parameters of a query, and every time something changes I want to trigger several events. What would be the most idiomatic way to do this with re-frame. I could subscribe to a map containing all the parameters, and then trigger an event handler?

@gklijs generally you don’t want to tie the output of a sub into running an event handler

it breaks the cycle of data

You could make an effect which handles the rerunning of the events?

Yes, only thing with that is that each parameter change would be a effectfull event handler

But that's probably the cleanest way.