Fork me on GitHub
#re-frame
<
2015-10-19
>
Pablo Fernandez07:10:50

What’s the best way to reset forms with uncontrolled inputs?

shaym14:10:11

i am seeing two events in the logs one after another but the second event app-state is not the result of the first event

shaym14:10:38

first event sets acme123 to {}, but on the second one its nil

shaym14:10:42

is there some-kind of a concurrency issue here?

danielcompton18:10:06

@shaym can you show the line after this showing the only after for :generic-get-response?

shaym20:10:42

@danielcompton: utils.js:6 only after : {:data {:acme123 {:_id "acme123", :name "acme123"}}}

danielcompton20:10:15

@shaym I’m guessing that it’s an artifact of an empty map being treated as nil by the data diff

shaym20:10:22

@danielcompton: hmm i was suspecting it also , ill try running some tests with a {:content "content" } marker instead of an empty map

danielcompton20:10:51

yeah, or just print the map before you run the body of :generic-get-response

shaym20:10:21

@danielcompton: is there any issue with dispatching handlers from within a subscription?

danielcompton20:10:36

You probably shouldn’t be doing that

danielcompton20:10:45

don’t cross the streams

shaym20:10:03

i am trying to implement lazy data loading

shaym20:10:27

i.e. if the data is not in the atom , trigger an ajax call to get it

shaym20:10:40

@danielcompton: how would you suggest implementing it

shaym20:10:05

it mostly works ok , but i do see some weird handler flows at times

danielcompton20:10:25

In the app we’re working on, remote data sources stay as subscriptions, i.e. we subscribe and get data in the subscription, but it doesn’t get put into app-db

danielcompton20:10:32

But that’s not applicable everywhere

shaym20:10:35

at times it works really nicely , i.e the recation returned by the subscription is initially empty , but then when the ajax call returns , it all updates "automagically" simple_smile

shaym20:10:22

yeah the goal is to have it in the app-db to avoid further ajax calls

shaym20:10:26

since dispatch is async i assumed that triggering it inside a sub will be fine

mitchelkuijpers20:10:42

@danielcompton do you have a code example for that. We currently put everything in app state

danielcompton20:10:10

@shaym the issue with lazy loading is how you garbage collect it in the end?

danielcompton20:10:26

otherwise your app-db will just keep growing

shaym20:10:34

this function is called from a subscription

shaym20:10:23

@danielcompton: i plan to add garbage clean , but for now im hoping state would not be too huge

danielcompton20:10:05

@mitchelkuijpers: I don’t have a clean extractable example for you, but the gist is you make a subscription which returns a blank ratom/reaction. It runs a query asynchronously and when the response comes back it updates the Reaction.

danielcompton20:10:22

@shaym yeah it’s a good one

shaym20:10:30

and was trying to implement something similar

danielcompton20:10:28

A thought off the top of my head would be to setup a bunch of lazy loaded subscriptions in app-db from a handler, then when you subscribe to them they get realised

danielcompton20:10:00

although that’s mostly a semantic difference. I haven’t looked at how Elm does it, but there’s probably some smart ideas over there

shaym20:10:04

maybe a non UI related handler , that has a subscription on a queue of ids to load , and trigger ajax calls for them

shaym20:10:14

but i dont know how to implement something like this

shaym20:10:26

maybe a hidden page element

shaym20:10:05

not a very pretty solution 😞

mitchelkuijpers20:10:22

Thnx @danielcompton never realized I could do this

danielcompton20:10:30

@shaym I think there’s definitely a good case for doing this, I’m just not sure exactly what it is

danielcompton20:10:30

@shaym actually, I had a thought. When you setup a page, you could run a bunch of handlers to fetch data, that no-op if the data is already present. However that’s still not quite right

shaym22:10:33

@danielcompton: yes that is an option , but it will spread the fetch calls all over the app and make them page specific , having a generic handler makes it a single point of contact

danielcompton22:10:05

for sure, I think this was why we went down the route of subscriptions for remote data