This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-12
Channels
- # aleph (1)
- # beginners (81)
- # boot (20)
- # cider (46)
- # cljs-dev (6)
- # cljsjs (6)
- # cljsrn (8)
- # clojars (2)
- # clojure (104)
- # clojure-berlin (3)
- # clojure-italy (4)
- # clojure-losangeles (2)
- # clojure-nl (16)
- # clojure-spec (16)
- # clojure-uk (28)
- # clojurescript (88)
- # core-logic (31)
- # cursive (8)
- # data-science (3)
- # datascript (1)
- # datomic (95)
- # docs (1)
- # emacs (6)
- # figwheel-main (24)
- # fulcro (106)
- # graphql (5)
- # hyperfiddle (2)
- # midje (2)
- # nrepl (1)
- # off-topic (14)
- # om-next (1)
- # parinfer (2)
- # pedestal (26)
- # portkey (2)
- # re-frame (11)
- # reagent (27)
- # ring (6)
- # rum (4)
- # shadow-cljs (33)
- # spacemacs (10)
- # specter (53)
- # tools-deps (17)
- # vim (31)
for the sake of cache validation and garbage collection, what's the right way of marking entities in app db with timestamps when they were loaded?
@tony.kay I just tested here, performance-wise it seems fine, but some stuff got broken, mostly related to things that I use modals/floaters (my guess is event related) with, I'm not sure why, it's not everywhere, but I have some modals that dont close once opened, other times I can open a popover once, then it stops working, and I'm getting no errors
and I think there is still problems with react-key, seems like it's not working when I send :react-key "something"
to the factory function call, eg (some-thing {:react-key "bla"})
I didn't find the code for 2.6.0 in the fulcro repo, is that pushed?
@wilkerlucio oops. I had not. feature/component-refinement. Some of the changes are probably going to be reversed. I was thinking I had to add separate hooks for upcoming v17, but this other approach seems better.
cool, what is the other approach?
I was putting in hooks for the lifecycle rewrites so they could be different based on react version.
but I was able to fix Fulcro to not need the deprecated lifecycle methods, so now it should just be fwd/bkwd compat
I would like to try finding out why my events seems broken, but I'll probably only have time to do it late tomorrow
I have a lot minor event related things that seems to got broken after the update
but like I said, not sure what/why, they just stopped working and I see no errors
that really should not be…so I did decide on the data diffing we had discussed. I’m using the tree-path to the components to update the tree props and rendering from root (s.c.u short-circuits things that didn’t change)
I guess it is possible the “path to the rendered data” (which ends up as an assoc-in update) is wrong in some corner cases? Are those always around unions?
I'm not using any unions, so must be something else
all refreshes are proper “react way” (from root) now instead of tricky force renders…so it should have cleared up more bugs than it made 🙂
the issues seem related to using events in the way I described here other day (using react elements to manage events, mostly keyboard or things outside the current dom tree)
I didn’t touch anything related to events…so that’s just weird…React version change? Fulcro is using 16.4 now
I'm still on 15.6
(well, in that branch it is…I’ll default it back to 15 prob on release). Make sure it didn’t “upgrade” you…I guess you’re using shadow though?
yeah, using shadow
can be related to lifecycle
those event elements use then
ok. Also, looks like I introduced a bug in refresh declared on mutations…I think the old path-meta function is stomping on metadata instead of updating it
@tony.kay I did a little experiment, and it seems like the render is failing to be called after some condition (not sure what yet)
I'm triggering a value change on my component, but it's not calling the render method
I see the value changing on inspect, but render is not called
just a sec and I can push a version with some extra debug logic in it that would help
pushed. Here’s the new logic: 1. refresh list comes in. 2. Find components in index (this is the “requested refresh”) 3. Find data path on each, and remove those whose parent will refresh (so no dupe renders) 4. Render the non-dupes
There could be a bug in the dedupe logic, so I added log statements to show the “whole list” and the “pruned list”
pushed on snapshot or just on the repo? (just asking because I tried updating deps and didn't got a new one)
@tony.kay you forgot to use cljs reader macros on the debug info
ExceptionInfo: failed to require macro-ns "fulcro.client.primitives", it was required by "fulcro.client.primitives"
clojure.core/ex-info (core.clj:4739)
clojure.core/ex-info (core.clj:4739)
shadow.build.macros/load-macros/fn--16367/fn--16374 (macros.clj:73)
shadow.build.macros/load-macros/fn--16367 (macros.clj:70)
shadow.build.macros/load-macros (macros.clj:60)
shadow.build.macros/load-macros (macros.clj:51)
shadow.build.compiler/post-analyze-ns (compiler.clj:45)
shadow.build.compiler/post-analyze-ns (compiler.clj:42)
Caused by:
CompilerException: java.lang.RuntimeException: Feature should be a keyword: (js/console.log :filtered-refresh (dedup-components-by-path components-to-refresh)), compiling:(fulcro/client/primitives.cljc:1949:91)
clojure.lang.Compiler.load (Compiler.java:7521)
clojure.lang.RT.loadResourceScript (RT.java:379)
clojure.lang.RT.loadResourceScript (RT.java:370)
clojure.lang.RT.load (RT.java:460)
clojure.lang.RT.load (RT.java:426)
clojure.core/load/fn--6548 (core.clj:6046)
clojure.core/load (core.clj:6045)
clojure.core/load (core.clj:6029)
Caused by:
RuntimeException: Feature should be a keyword: (js/console.log :filtered-refresh (dedup-components-by-path components-to-refresh))
clojure.lang.Util.runtimeException (Util.java:221)
clojure.lang.LispReader$ConditionalReader.hasFeature (LispReader.java:1509)
clojure.lang.LispReader$ConditionalReader.readCondDelimited (LispReader.java:1545)
clojure.lang.LispReader$ConditionalReader.invoke (LispReader.java:1645)
clojure.lang.LispReader$DispatchReader.invoke (LispReader.java:843)
clojure.lang.LispReader.read (LispReader.java:275)
clojure.lang.LispReader.readDelimitedList (LispReader.java:1384)
no worries, I'm also doing other things, doing in bits when I can
@tony.kay check this: https://www.dropbox.com/s/fky3py0kv3cn4sk/Screenshot%202018-07-12%2011.19.58.png?dl=0
this component is a custom dropdown, when I just toggle to show and hide it works fine
but when I pick an element, it goes away fine, but after that the component doens't trigger the render anymore
(the boolean is the flag to if the dropdown is expanded or not)
so, what I want to know is: - Is the UI element that you expect to refresh even in the “requested”, and if so, does it errantly get removed? If it isn’t even making it into the refresh list that is one problem. If it is in the “filtered” list, but not rendering that is a shouldComponentUpdate bug probably. If it isn’t in the list, it could be a bug with lifecycle and indexing of the components
@tony.kay the log "RENDER" is from the Dropdown component, it is in both lists (refresh and filtered), but the actual render function is not called, if it were we would see the RENDER
log
from the options you mentioned, seems a bug in shouldComponentUpdate
@wilkerlucio so I’m wondering what that component’s path is. When it does render, could you log out the metadata on props
?
sure, one sec
@tony.kay interesting
after I do select an item, the meta turns into nil
seems to happen when the parent is refreshed
ok, so that is probably part of the problem…I’ll think through how that could happen. That path is important for the new refresh
in this example it's a simple demo (not a big app), the DropdownContainer is the root (almost, there is one of those very clean aroudn it) and it has the Dropdown in
when I just update the dropdown, it keeps working fine
but when I trigger the action, this causes a mutation on the parent (DropdownContainer), the meta seems to get lost after that
this one uses a lot of computed props, not sure if it makes a difference
in this SS I was logging (meta props)
@tony.kay I just created a minimum repro for it
(fp/defsc ComputedChild
[this {:keys [my-value]} {:keys [on-select]}]
{:initial-state (fn [_]
{::id (random-uuid)
:my-value "initial"})
:ident [::id ::id]
:query [::id :my-value]
:css []
:css-include []}
(dom/div
(dom/div "VALUE - " my-value)
(dom/button {:onClick #(fm/set-value! this :my-value "A")} "Set local A")
(dom/button {:onClick #(fm/set-value! this :my-value "B")} "Set local B")
(dom/button {:onClick #(on-select "From inside")} "Call computed callback")))
(def input-component (fp/factory ComputedChild))
(fp/defsc DemoContainer
[this {:keys [input ui/local-value]}]
{:initial-state (fn [_]
{:input (fp/get-initial-state ComputedChild {})
:ui/local-value "initial"})
:ident (fn [] [:id "singleton"])
:query [:id {:input (fp/get-query ComputedChild)}
:ui/local-value]}
(dom/div
(dom/div "Outer - " local-value)
(input-component (fp/computed input {:on-select #(fm/set-value! this :ui/local-value %)}))))
when you click on the buttons of the ComputedChild, it updates fine
but if you click to trigger the computed callback, after that the local thing on ComputedChild stops updating
but it does update if you force a change on the DemoContainer (like by clicking on the "Call computed callback" button again)
seems like updating the a parent is breaking the children capability to refresh itself
@wilkerlucio should be fixed now
@tony.kay This is by no means high priority, but I can't attach metadata to defsc
because this line tramples it: https://github.com/fulcrologic/fulcro/blob/7ff0db1f42c49b7def5ed0409c70404b940e500f/src/main/fulcro/client/primitives.cljc#L3179