it looks like the only thing there is the query id. is there any way to get the db? I have a set of keys in there that have corresponding subscriptions. I was going to use them to create the subs

@eoliphant be sure to read through https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md And take particular notice of the link at the bottom to the todomvc example app, it is heavily commented and will likely provide the answers you seek

But to answer your questions: 1. Layer 2 have direct access to app-db. And consequently they will rerun every time app-db changes in any way. So we make them trivial. 2. Layer 3 has access to one or more Layer 2 subscriptions (but not app-db directly) and creates "materialised views" of the raw data extracted by Layer 2

We never want Layer 3 accessing app-db directly because, if that were the case, the Layer 3 sub would have to re-run every time app-db changes for any reason.

So, Layer 2 acts as a way of pruning the propagation of values through the signal graph (short-circuiting unnecessary computations) , when app-db has changed in some way, but not the part "of interest".

Yeah, I’ve got the flow down. But yeah I see the issue if you make app-db available

You really don't want app-db ... you want some part of app-db

right

And that's what a layer 2 subscription provides

and I’d done that. but my issue, and granted maybe I didn’t do this the best way lol, is that I’ve got a form, and I have dynamic subs that I can use to get a given field’s values, validations, etc. So [:field-val x] [:field-valid x] etc. That all works fine

but I wanted to check all the fields prior to submission. Basically have my signal function return a vector of subscribes to the [:field-valid] for each field, then just run an every? or whatever in the calc function

Won't this submit be handled in an event handler?

so I can say return a sub for the form-data, etc. But then it’s the raw data, and I don’t reuse the validation check in the field level validation

yep

This forms stuff is not really my era. There are re-frame forms libs. Have a look in ExternalResources docs

They may have some ideas

yeah i’ve been poking around with those, the more flexible one free-form, says validation is pluggable, but has no examples lol

but i’ll do some more digging

👍

ok i got it to work. I’m just not sure how I feel about it lol

I used my sub that points to the map of fields in my component, i then passed that result to my are-all-fields-valid? level 3 sub. From that I just mapv over the list to get subs. Works, just feels a little clunky lol

Anyone having an idea how I can hide the re-frame-10x window during tests with etaoin? Or is it possible to start with the re-frame-10x window hidden?

Press Ctrl-H

I mean mean with code, sorry I wasnt clear.

@sveri in my project with re-frame-10x it's hidden on start-up, but I thought that was the default. Not sure what's different. But with etaoin you must likely want to test against a production build right?

@gklijs I write my tests while developing and run them parallel, easier than clicking through the UI all the time. I wonder why it is opened per default, OTOH it is also opened whenever I open my browser.

Might be a browser specific thing, I use chrome, and it never opened when opening the page, neither when opening with etaoin.

@sveri https://github.com/Day8/re-frame-10x/issues/181

(mranderson047.re-frame.v0v10v2.re-frame.core/dispatch [:settings/user-toggle-panel])

I’ve used reagent and re-frame quite a bit now, but I’m still at times struggling to resolve the warnings about Every element in a seq should have a unique :key:

is it the children of ui.element.containers.views.container

@hkjels if you are creating children using, e.g., a for then you need to add a ^{:key "unique-something"} before the child form

@hkjels > but I’m still at times struggling to resolve the warnings look at your (for [item coll] [:div .... forma and make sure a unique {:key "some-unique-key"} is provided.

ha ha synched!

That’s what I usually do, but the problem did not lie within a loop I changed the form of one of my components from [cotainer params content] to (into [container params] content) and it was satisfied

that's because your into returned a vector

perhaps i misunderstand your context…

this is an issue with any component that takes & children

you have to use into to get rid of the need for keys, otherwise reagent sees & children as a list and expects it to have keys

I’d love to get some opinions on the use of graphql with reframe. The two strategies seem kind of opposed to one another? Graphql is a fetch-only-what-you-need every view, and keep refetching because the payload is optimized thanks to the query. A well structured rf db is capable of avoiding a ton of fetches because its easy to update in a single place, and derived values prevent stale views

Normally in rf I would normalize the database and all my views pole subscriptions from the database. If I’m going to fetch all new data every view though with graphql, I don’t see any downside to name spacing a slice of the database and tying it straight to my view. Normally this would be a bad idea, But does it really matter if you’re just re-fetching exactly what you need on every view?

@lwhorton you can get away with that in a lot of cases, and it is a lot simpler. For complex views where you edit multiple records, but need a consistent view, it may not be good enough

For example if you have comments { ... person { name } }, and look at one comment, edit person.name, then go the next comment. (Not realistic maybe, but you get the point)

does anyone have any advice on how to decide what to put in a subscription vs. in the view code? the basic mantra, of course, is that views should be as dumb as possible, but it seems like on the opposite end there is the risk of putting too much view-specific content in subs. For instance I have a text SVG element in one of my components. Some of its attrs are functions of db state, and some are hard-coded, something like this:

[:text 
 {:font-size 12
  :y @(rf/subscribe [:some-sub])
  :x @(rf/subscribe [:some-other-sub])}
  @(rf/subscribe [:another sub])]

@lgessler One way to think about it would be whether you could reuse the subscriptions for different targets, like DOM vs React Native. If it is too specific, then you couldn't, which would be a shame. May also not be a huge problem, though

thanks, that's one useful diagnostic question for sure

@lgessler so i guess it’s about frequency of change. if only one of those change a lot, and that one thing has many subscribers, then you probably want to split it out. but if a handful of things are all used together and change together, then they likely belong together

excellent point, thank you. that performance matter is something I hadn't considered. That's probably the most important consideration in this particular circumstance since these subs are getting hit a lot