This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-10
Channels
- # admin-announcements (1)
- # alda (1)
- # bangalore-clj (1)
- # beginners (94)
- # boot (139)
- # braveandtrue (1)
- # cider (19)
- # cljs-dev (21)
- # cljsjs (8)
- # cljsrn (79)
- # clojure (124)
- # clojure-austin (1)
- # clojure-belgium (1)
- # clojure-berlin (3)
- # clojure-hamburg (3)
- # clojure-quebec (1)
- # clojure-russia (77)
- # clojure-spec (5)
- # clojure-uk (18)
- # clojurescript (39)
- # conf-proposals (21)
- # core-async (5)
- # cursive (8)
- # datomic (40)
- # defnpodcast (1)
- # devcards (14)
- # dirac (5)
- # editors (1)
- # emacs (4)
- # jobs (1)
- # liberator (4)
- # onyx (29)
- # perun (15)
- # proton (15)
- # protorepl (9)
- # re-frame (47)
- # reagent (38)
- # ring (1)
- # rum (7)
- # specter (23)
- # untangled (8)
- # yada (55)
i remember reading somewhere recently that there's a new reset!
that returns nil instead of the value. anyone have a link to that?
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? đ
@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)
On my phone so got to use replete :)
Also, I'm getting really curious about what you're working on now :)
Oh I don't expect it - totally going to imagine different preposterous things now though.
@mikethompson: my PR put the logo
directory top level but you moved it in the meantime so you got two now..
@mikethompson: also for that reason the logo in the readme is the old version
Looking
Got it. Will move them around and sort it out.
Thanks
np đ
Hmm. In /logo
there isn''t a sketch file.
for some reason the sketch file is in /image/logo already
last commit is the same as in /logo
Right. We're good then
So develop should now have the right arrangement, including the right one on display: https://github.com/Day8/re-frame/tree/develop
yep, looks good to me
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
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
@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?
more of the general issue, maybe the application iâve written is doing a lot, but it seems to not be very responsive
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
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
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.
@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?
yeah, i have a key-value pair in the app-db with key :active-modal and a value of the component itself
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.
@nanuko: are you using debug
middleware? That does a deep comparison which can take a long time.
Obviously you wouldn't be doing it in production
@mikethompson: no debug middleware. this is after it has been minified
There's a page in the Wiki .... "Eeek Performance Problems"
@shaun-mahood: that might be good idea, iâll try that
@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