Fork me on GitHub
#re-frame
<
2016-01-27
>
yenda11:01:50

Is the dynamic subs exemple in the wiki correct ?

yenda11:01:22

I wonder why the params of the inner todo-dynamic function are like this

yenda11:01:35

I would have expected

yenda12:01:36

also I am not sure why todos are dereffed since :todo-dynamic doesn't seem to return a reaction

mbertheau12:01:48

Is it correct to say of a Form-2 component, 1. the inner render function is called again when an atom that was deref'd inside it, changed since the last call 2. the outer function is called again when the function argument values are different from last time

jaen12:01:24

Not exactly, I think.

jaen12:01:56

Outer is called on component mount, to create a new instance of component, with render function being the function returned by the outer function.

jaen12:01:04

So the inner function is called when a new real DOM is needed because props/ratoms/state changed.

jaen12:01:29

Outer function is called, when the virtual DOM structure changed by adding a new component.

jaen12:01:33

At least, I think so.

mbertheau12:01:45

Hmm, so the outer function isn't called again when the function argument values change. Then I wonder how https://github.com/yatesco/re-frame-stiching-together/blob/master/src/cljs/demo/views.cljs#L161 works. cc @colin.yates . Ah, it works only because attaching the key in https://github.com/yatesco/re-frame-stiching-together/blob/master/src/cljs/demo/views.cljs#L78 leads to a different component instance. That seems cludgy.

colin.yates12:01:06

hi @mbertheau - I haven’t used re-frame for a while and that repo was a ‘discovery-at-the-time’ so not much to add unfortunately.

colin.yates12:01:28

and yes, adding a key is a hack

yenda13:01:07

why is it a hack ?

yenda13:01:44

react is expecting a key to be able to render only a specific component more effectively

yenda13:01:04

adding the key as meta data is just the way to do that it doesn't seem like a hack

yenda13:01:12

ohhhh it's a hack in that particular case sorry for misunderstanding

hugobessaa15:01:59

anyone tried to expose local state in re-frame apps?

hugobessaa15:01:15

I want to inspect and serialize all local state

hugobessaa15:01:26

Would dispatch-sync a [:create-local-state key] inside a [:local-state key] subscription be something not great?

yenda15:01:51

you mean to check the state of the app ?

yenda15:01:44

I made a component to pr-str what I pass to it and I just inspect stuff like that when I'm in development phase

yenda16:01:14

the app-db itself grows too fast to be inspected

yenda16:01:40

but you can just make a subscription that takes it all

hugobessaa16:01:03

I mean exposing form-2 local atoms

hugobessaa16:01:48

To have some state that is scoped to a single component, but is accessible from serializers

hugobessaa16:01:16

much like om component's state

yenda16:01:36

if you want to serialize maybe it shouldn't be in local state

yenda16:01:11

having everything in app-db is really handy to restore session

sooheon17:01:54

@yenda: how do you do that btw? I’m having trouble understanding how to approach persisting app-db across reloads and such.

yenda17:01:49

I do it in a really hacky way atm, just printing it in the console and copying the result in the default-db

yenda17:01:36

but when I will want to persist it properly I will just send it to the server and store it

jaen17:01:39

Hm, why send to server instead of using local storage?

yenda17:01:33

it depends where you want to persist

jaen17:01:49

True, but I thought you were talking about local state; doesn't sound like something you would want to persist server-side.

hugobessaa19:01:46

my app has a great number of forms

hugobessaa19:01:58

I don't want to hide input values inside local states

hugobessaa19:01:19

I will think about this better

hugobessaa19:01:45

maybe what I want isn't a way to expose local state, but to hold initial values and edit values

shaun-mahood20:01:58

@hugobessaa: How many forms are you talking about? I've tried a few different methods but might be at a much smaller scale.

hugobessaa20:01:57

i'm talking about maybe a hundred

hugobessaa20:01:15

not simple ones

hugobessaa20:01:39

it's a saas for companies hr

shaun-mahood20:01:40

Is the data loaded from a server when you browse to one of them or is it all held locally?

hugobessaa20:01:52

loaded from the server

shaun-mahood20:01:10

Ok, what I did might apply but it works for us on a much smaller scale.

shaun-mahood20:01:17

In my app db, I've got :page-state {} and :editing {}, and each time I browse to a new form the values are blown away and populated for the current form

shaun-mahood20:01:03

I've tried with 1 map per form but this seemed to do everything easier. When the form is submitted it sends over the values from :editing, and on success I just grab the current server values - one extra round trip didn't make any real difference for our app and made it much simpler

shaun-mahood20:01:39

Then each form has a name, and I've got :main-panel defined that just takes a keyword of that name.

shaun-mahood20:01:49

Which then determines what form I'm in

shaun-mahood20:01:52

Did I explain that in a way that makes sense? It's worked pretty well for me, can do both simple and complex pages with reasonable ease, but I don't have as many forms as you do

danielcompton20:01:00

@mbertheau: do you understand dynamic subscriptions now, or is there something still unclear?

hugobessaa20:01:33

@shaun-mahood: Nice! I will be looking into a way to simplify form data loading and editing states. Thx

hugobessaa21:01:21

@shaun-mahood: as I have multiple forms per page, and want to persist editing state even before reloading, I will store them inside maps :)

hugobessaa21:01:35

@danielcompton: thx! Already read everything in the wiki but it always nice to read again

shaun-mahood21:01:59

@hugobessaa: It gets a bit complicated, I did the same thing for my more complex pages too. It was my first experience trying to work with more deeply nested data structures, which was definitely a learning curve, but overall it worked pretty well for me

hugobessaa21:01:33

I'm solving some pretty nice problems. I will share my learnings

shaun-mahood21:01:38

I really tried to make it so that I can just look at my app db and see the whole state that I care about, it really brings so much value having such easy debugging

danielcompton21:01:42

@hugobessaa: reading that again, if there’s data that you want to access from other components that is currently component local, you probably want to move it into app-db

hugobessaa21:01:57

@danielcompton: I want "after" middleware to read them and instrument for debugging and persisting

danielcompton21:01:14

https://github.com/Day8/re-frame/wiki/Debugging will let you trace values and computation, you could probably mod it to persist them too?

shaun-mahood21:01:37

@hugobessaa: Not sure if it would work for your purposes at all, but I've also experimented with adding a sort of :history map to my app db to keep track of how things got to where they are - I just dispatched twice on the specific things I cared about. Not sure the idea totally made sense, but it might help if you're only looking for a couple specific things

hugobessaa21:01:30

@danielcompton: yep, totally possible

shaun-mahood21:01:37

Sounds like you're doing something interesting though, which is pretty cool especially as HR forms are about the most boring thing I can think of simple_smile

hugobessaa21:01:53

@shaun-mahood: not for this use case, but yep for others. I will have "transactional data" and "committed data". Maybe other stages like "locally committed" and "server committed"

hugobessaa21:01:17

Will think about this. You pals helped me a lot to think deeper about this

shaun-mahood21:01:07

Oh those are good categories to break into - I especially like knowing the difference between locally and server committed.

hugobessaa21:01:35

The whole point of that saas I'm working on is to make it less boring and give better data to HR people

shaun-mahood21:01:32

Sounds like a good idea, based on the HR programs I've looked at it's pretty needed.

hugobessaa21:01:00

Specially here in Brazil

hugobessaa21:01:08

An unsolved problem for sure

hugobessaa21:01:36

Re-frame has been essential to control incidental complexity

shaun-mahood21:01:25

Yeah, I'm a big fan of re-frame.

hugobessaa21:01:47

I implemented an employee directory with search, pagination, sorting, visualization and filtering. Went great. But I got worried after creating too much page specific state.

shaun-mahood21:01:17

I had to start over from scratch a couple of times on a small app to really figure out how to use re-frame in a way that worked well for me, but each time I started over I understood so much more about how it worked. It was also my first Clojure project, so that added a bit of extra learning overhead.

hugobessaa21:01:03

Anything open source? Share what you learned :)

shaun-mahood21:01:00

Nothing open source unfortunately. I guess I should build and open source something based on it as an example.

heeton23:01:03

Can someone point out what I’m doing wrong with this reaction? https://gist.github.com/heeton/1edc3d5f48d3bd9a9690

heeton23:01:13

I have a “current-town” subscription, and if I update the db in a handler, bits of my view update fine. But the part of my view that involves filtering a subscription doesn’t update. I’ve tried using reactions in various ways but can’t seem to make it work

heeton23:01:49

You can see the issue in this live demo - http://17c04073.ngrok.com/#