how can i create <video controls></video> with localized-dom?

@veddha.riady (dom/video {:controls true}) outputs <video controls></video>

@claudiu thank u so much!

@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 ?

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

@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 😛

what is Suspense, any links ? 😅

@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.

(and hide js-ugliness if I can 🙂 )

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

and OMG is that ugly (looking at Suspense examples)

didn’t someone really smart once write that “throwing for flow control is a very bad idea”

yeah I don't get that part either

it used to be render(data) => view

now its stateful promises everywhere even without the throw part

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.

well what wasn't possible before is "waiting" for a render

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

so that is neat just the implementation is straight up weird

loading spinners suck

Ah, I see your point. Yes. Being able to avoid a loading spinner for short wait is nice

but that is a really easy problem to solve other ways

not sooo simple really

but yeah all the examples they use have better solutions IMHO (eg. fulcro)

I was thinking that since Fulcro controls the network layer it would be pretty easy to hide timeouts for it in that layer

some kind of “deferred” load marker

just had never occurred to me

yeah the problem is that they are trying to solve it at the React level for generic React components

not for your own fulcro app

I don't think its a useful thing for them to solve either but here we are ...

time to port to an alt dom diffing lib? 😜

kidding…I like access to general react lib ecosystem

yeah ... although I'm beginning to change my mind on that subject as well

https://react-hocs-in-the-wild.surge.sh/

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.

this is not a world I want to live in 😉

Wow

yeah agreed

higher-order CRAP

somebody just took a functional dump all over their production code 😜

unfortunately this is what you get when you use @material-ui and many other react libs

its fine until you look too close 😉

yeah, but then you can make a case to rebuild that bit once you’re making money on the code

OSS ecosystem is great for startups…makes a mess, but you make it fast

yeah agreed

often the diff between life and death

just wondering if Suspense really is the solution to those problems

I haven’t seen the code for the heavy render vs interactive bit…

I thought doing XHR requests and everything was "bad practice" but now they are putting it all over the place

just the demo

yeah thats still missing

I think you can enable it with unstable_ConcurrentMode but no idea how to use it

how would you suspend something heavy in js that was already running, and not coded to interrupt itself?

workers?

well its a loop somewhere so the loop should just interrupt itself

the components shouldn't have to worry about it

but in his demo, it seems like the heavy render doesn’t interfere with the input

and if that’s a tight loop in js…there’s no way to do it with the one UI thread

requestIdleCallback

but you have not gone idle

oh wait…you don’t have to interrupt the code the USER wrote…only the react diff

Ah

that’s the trick

yeah

ok, so that’s something they do have to handle

well not really imho

still haven't figured out what they do exactly though. will dive deeper. maybe it makes sense when I figure it out 😛

it just feels bad but they must have a reason to do it that way

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”

I think they basically wrote their own thread scheduling library

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

(and display a “loading…” indicator in the meantime)

load markers already make that easy….not sure what you’re suggesting this adds

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

mutations do implement a multimethod

in the past i’ve written a helper function that takes in mutation name, test-env, and params

and it calls the underlying multimethod

which returns an action

then invoked that action

this way i could run the action’s of a sequence of mutations in a unit test

does that make sense?

as you can see here https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/mutations.cljc#L62

yes @currentoor, do you have an example of this setup?

the multimethod is called fulcro.client.mutations/mutate

no it was a commercial project but i can put together a quick gist

give me a minute

thanks 🙂

no worries, i just need to open up my project to make sure it works

don’t want to give you broken code 😅

in the meantime you can look at the link i pasted above

defmutation is just a cleaner way to wrap a multimethod

@pvillegas12 here a go https://gist.github.com/currentoor/8c482c1440ca0fb1dfae24a305fca070

let me know if anything doesn’t make sense

also, you could even make a wrapper function that takes in arguments like prim/transact! and uses run-mutation under the hood

When developing a Fulcro application in devcards there is an option to display the state. Is there a way to log mutations as well? Or would you just use Fulcro Inspect for this?