This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # aws (2)
- # beginners (147)
- # boot (19)
- # cider (57)
- # clara (52)
- # cljdoc (18)
- # cljs-dev (14)
- # cljsrn (4)
- # clojure (176)
- # clojure-conj (9)
- # clojure-dev (9)
- # clojure-germany (2)
- # clojure-italy (4)
- # clojure-spec (13)
- # clojure-uk (56)
- # clojurescript (72)
- # code-reviews (11)
- # cursive (17)
- # data-science (1)
- # datomic (52)
- # duct (26)
- # emacs (6)
- # events (9)
- # figwheel (1)
- # figwheel-main (21)
- # fulcro (132)
- # funcool (1)
- # graphql (3)
- # jobs-discuss (42)
- # leiningen (3)
- # luminus (45)
- # mount (10)
- # off-topic (2)
- # re-frame (17)
- # reagent (12)
- # reitit (20)
- # ring-swagger (7)
- # rum (3)
- # shadow-cljs (256)
- # slack-help (15)
- # sql (7)
- # tools-deps (50)
- # uncomplicate (1)
- # yada (9)
@tony.kay With the new updates in the fulcro rendering is there any performance difference between
prim/transact! reconciler an
prim/transact! component or
df/load on component/reconciler ?
Yes. Everything in Fulcro is like a React Pure component, so you never diff/update anything whose props haven’t changed. That means a render from root for React is pretty good. The query is where you are tuning overhead. Re-running your root query can be quite a bit heavier than re-running a local component’s query. The current rendering algorithm still uses the follow-on reads and idents to refresh the data for components in the query result (it patches the last render’s query with local data). Thus, working against a component with an ident will be significantly faster than working agaist the reconciler or root node. ALso, there are plans to further optimize the render so that we can carry updated component props via React’s component-local state internally to make things even faster, and of course that won’t happen if you’re going against the reconciler…you’ll just get root everything then.
Could anyone point me towards an example that has one view with a list of objects and another with one particular object. I have a router working, but I'm not sure how best to represent the current object.
@ben735 Not exactly sure what you're looking for. http://book.fulcrologic.com/#BasicRouter has an example with simple object and for list of objects it's like in the PersonList example here http://book.fulcrologic.com/#_automatic_normalization
There is also a nice video about routing inf fulcro https://www.youtube.com/watch?v=HJBI24yAdBQ&index=11&list=PLVi9lDx-4C_Rwb8LUwW4AdjAu-39PHgEE
Thanks, I'd better go watch that. I'm aiming for eg. a page with a list of people where you click on one and you navigate to a page with details about an individual person
@ben735 For the example you mentioned this seems what you're looking for http://book.fulcrologic.com/#_combining_routing_with_data_management
https://gist.github.com/claudiu-apetrei/57ed1bd4e681e6466a93b98cd0e4c133 Hacked together what you mentioned.... code needs cleanup but hope it helps
@claudiu thanks again, I've just worked through it and your code was super-useful. Much appreciated!
@tony.kay do you have any thoughts on integrating Suspense with Fulcro’s data fetching story once it gets officially release?
is Suspense finally out? lets see what a mess they created .. throwing Promises looked so ugly the last time I checked 😛
It’s not out yet, but the latest release includes a feature (React.lazy) relying on suspense. It should be out soon-ish
@hmaurer Have not had time to look at it yet, but of course I’ll want to support it well if it brings advantages to Fulcro users.
Suspense is also what I’ve been waiting on to drop before I consider re-optimizing render, since the new async stuff could break things
didn’t someone really smart once write that “throwing for flow control is a very bad idea”
I watched the talk back when Dan gave it. I like the idea of being able to prevent (or abort) a heavy render while doing interactive stuff (like typing in a field)…Fulcro already has two of the advantages, I think: - data fetching without locking the UI. Not sure Suspense adds anything to the picture there we’d want. - common abstraction over loading state…already done in Fulcro. Again not sure what we’d gain. So, the “good experience for users with low-end, high-latency devices” is the one I’m interested in.
and OMG this sounds like a great idea from the 90's: “suddenly calling AJAX requests inside render will become OK”
ie. instead of displaying "Loading ..." right away you can now opt to wait for a result
Ah, I see your point. Yes. Being able to avoid a loading spinner for short wait is nice
I was thinking that since Fulcro controls the network layer it would be pretty easy to hide timeouts for it in that layer
yeah the problem is that they are trying to solve it at the React level for generic React components
well, when I’m trying to build software for businesses, it is really hard for me to make a case to rewrite a component (in 20+ hours) that is available and works for free.
unfortunately this is what you get when you use
@material-ui and many other react libs
yeah, but then you can make a case to rebuild that bit once you’re making money on the code
I thought doing XHR requests and everything was "bad practice" but now they are putting it all over the place
how would you suspend something heavy in js that was already running, and not coded to interrupt itself?
still haven't figured out what they do exactly though. will dive deeper. maybe it makes sense when I figure it out 😛
I think the whole idea is they bust apart the dom diff into bits (fibers) and schedule them…all while checking in between “is there some kind of event to deal with, or state change scheduled”
and instead of calling them “green threads” (showing my age here), they chose “fibers”
I don’t see how we’d implement that interruption…why do you think we can handle making an input work when the js UI thread is tied up doing DOM diff???
@hmaurer So, just looking at it, these are React primitives that they intend you to use directly in your components. As such, you could use them as-is today. Fulcro creates 100% (subclassed) React.Component instances. So, there is nothing stopping you from trying any of it now. In terms of it adding to Fulcro’s story….not sure yet.
The async nature probably requires that you use
with-parent-context for any content wrapped in async blocks
If I’m right about how they’re implementing the fiber stuff, then you should benefit from that in Fulcro without any internal changes to Fulcro itself.
The blog post says this:
In reality things are a bit more complicated than that: - with this approach we need to either implement the loading screen in the component which requests / consumes the data, or expose its API to parent - things get more complicated the more content we need to load (what if you wanted to load a movie details page only when the reviews and all images are also already loaded?) - once we start making use of AsyncMode things will get even more complex — parts of your application might have new data, parts of it old, which would lead to "tearing" or "flickering" of content
(1) is not true for Fulcro…already handled (2) also seems like we already have that in Fulcro…no need for anything special from React (3) A true statement: async rendering is likely to cause nightmares….you’re taking something that was sync and making it async…that’s a recipe for problems. And they have not said anything about how this API really solves that complexity.
I guess they are implying on (3) that having the ability to set “timeouts” on when something shows is the “fix” for flickering…in other words we, as developers, now we get to “guess” how long to wait (on varying devices) for things to happen before showing things. I guess that is ok…not sure I want to throw promises to do it.
@tony.kay thanks for the in-depth reply! Regarding (1), it seems to me that the part that is currently handled by Fulcro is to load data from the cache (through component queries), but you still need to make sure the data is in the cache by triggering a load (on route change, etc). That doesn’t seem incompatible with Suspense in the sense that you could use it to trigger loading data when a component is attempting to render, and only continue the rendering (and pull data from the cache) once the load has completed
So, for example, a top-level “page” component could use Suspense to indicate that data is not loaded in cache yet, trigger a load, and re-render once the cache has been filled up
think this is a job for a smart router. if you want this custom logic. got something like this built with fulcro
@claudiu the loading indicator isn’t the important bit though; that’s easily doable with fulcro right now; what I meant is that with suspense you could trigger data-loading at the component level
the ability to not have to trigger data loading before-hand (i.e. on route change), but only when a component is rendered? I am not sure that’s desirable, but…
why is that a concern of React? You are responsible for defining you “loading” story. It is trivial to write components/mutations that manage this in some consistent way and use that throughout your code.
As far as I can tell, then Async rendering story is the only thing Fulcro cares about…being able to prioritize interactive rendering over heavy component rendering is something I do need React to manage, since it owns the UI thread during DOM diff…if they make that “interruptible”, then that is quite useful.
Trying to find an example of testing mutations with fulcro, anybody has a good example spec?
(Normally I test the
mutation* functions, but in this case I have a mutation that delegates to
integrate-ident* so want to test that)
@pvillegas12 you could make a function wrap the call to integrate-ident* and test that?
yes I could do that @currentoor, my question is in general how to I test mutations? (sometimes the indirection is unnecessary as in this case caused by the desire to unit test it)
well that approach does work in general for unit testing mutations, but i see what you mean
in the past i’ve written a helper function that takes in mutation name, test-env, and params
also, you could even make a wrapper function that takes in arguments like
prim/transact! and uses
run-mutation under the hood