Fork me on GitHub
#re-frame
<
2016-08-10
>
johanatan00:08:59

anybody here now?

johanatan00:08:33

i remember reading somewhere recently that there's a new reset! that returns nil instead of the value. anyone have a link to that?

johanatan00:08:46

[i hope this isn't a figment of my imagination]

johanatan00:08:36

For some reason I was thinking it was called nreset! or some such but scanning both re-frame and reagent codebases didn't turn it up. Also reviewing recent release notes for both projects turned up nothing. Is this a manufactured memory of mine or did I truly see it somewhere? 🙂

shaun-mahood00:08:01

@johanatan: not sure on the existence of anything like that, but I think you could create your own in the meantime with something like (defn nreset! [x] (do (reset! x) nil)

johanatan00:08:17

yep, that's what i did 🙂

shaun-mahood00:08:19

On my phone so got to use replete :)

shaun-mahood00:08:34

Also, I'm getting really curious about what you're working on now :)

johanatan00:08:23

Can't say, unfortunately 😞

shaun-mahood00:08:51

Oh I don't expect it - totally going to imagine different preposterous things now though.

johanatan01:08:34

new in 0.6.0-alpha (reagent)

johanatan01:08:45

but alas no rreset!

martinklepsch11:08:20

@mikethompson: my PR put the logo directory top level but you moved it in the meantime so you got two now..

martinklepsch11:08:33

@mikethompson: also for that reason the logo in the readme is the old version

mikethompson11:08:02

Got it. Will move them around and sort it out.

mikethompson11:08:13

Hmm. In /logo there isn''t a sketch file.

martinklepsch11:08:59

for some reason the sketch file is in /image/logo already

martinklepsch11:08:25

last commit is the same as in /logo

mikethompson11:08:26

Right. We're good then

mikethompson11:08:10

So develop should now have the right arrangement, including the right one on display: https://github.com/Day8/re-frame/tree/develop

martinklepsch12:08:03

yep, looks good to me

lwhorton18:08:54

hrm.. is it normal for required fields to never actually trigger the browsers’ “hey this isn’t filled”? can’t tell if this is a reagent issue, or a re-frame async-dispatching issue

lwhorton18:08:09

thought of the solution almost instantly after asking that ^: for anyone interested: you have to label button type=submit, but on the :form provide a :on-submit handler, then everything works as expected… in an earlier framework I was using I think this was done automatically behind the scenes, so one could simply :button {:on-click #() :type “submit”} and the form would validate

nanuko20:08:11

are there any well known bottlenecks for re-frame?

shaun-mahood21:08:24

@nanuko: https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem has some information related to dealing with high CPU tasks, but other than that I'm not aware of anything. Have you got a specific set of characteristics for your app that you are concerned about, or are you wondering more in the general sense?

nanuko21:08:22

more of the general issue, maybe the application i’ve written is doing a lot, but it seems to not be very responsive

shaun-mahood21:08:09

It seems like there are a few things you can do in the design or code that can really affect performance - I'm happy to discuss further and see if there's anything that I can do to help

nanuko21:08:35

so one example is with a modal. when i press the button to activate that modal, there is a significant lag until the modal actually appears

shaun-mahood21:08:40

Not sure how far you've gone with troubleshooting yet, but one thing I've done in the past for similar issues was to log out to the console for each step in the data flow - I just added something like (.log js/console (str "handler 1: " (.getTime (js/Date.)))) to each step that I expected to run or the extra handlers / subscriptions that I suspected might be firing that shouldn't be. Pretty unrefined but it helped me validate my assumptions at least and usually rules out a few of the potential issues.

shaun-mahood21:08:00

@nanuko: There's also a few different ways I can think of to handle showing a modal - is there a particular pattern from an example you followed, or can you put up an approximation of how you are doing it?

nanuko21:08:19

yeah, i have a key-value pair in the app-db with key :active-modal and a value of the component itself

shaun-mahood21:08:33

Would it be easy to test what happens if you change the final action from rendering the modal to something like a javascript alert and see if it significantly changes how long it takes to fire? That should hopefully help to see if it's an issue with the subscriptions and handlers or the rendering of the modal.

mikethompson22:08:37

@nanuko: are you using debug middleware? That does a deep comparison which can take a long time.

mikethompson22:08:06

Obviously you wouldn't be doing it in production

nanuko22:08:13

@mikethompson: no debug middleware. this is after it has been minified

mikethompson22:08:39

There's a page in the Wiki .... "Eeek Performance Problems"

nanuko22:08:52

@shaun-mahood: that might be good idea, i’ll try that

nanuko22:08:21

@mikethompson: item number 2 from that wiki page might be part of my issue, i have a prop which holds a lot of component state. may need to move that into app-db