Fork me on GitHub
#fulcro
<
2018-10-24
>
veddha04:10:31

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

claudiu07:10:35

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

veddha07:10:03

@claudiu thank u so much!

claudiu08:10:29

you're welcome 🙂

claudiu08:10:06

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

tony.kay14:10:04

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.

Sturm10:10:45

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.

claudiu10:10:04

@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

Sturm10:10:46

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

Sturm10:10:39

Hmm, can't seem to see any routing going on in the PersonList examples.

claudiu10:10:29

yep, the person list is just how to model the data

claudiu11:10:45

welcome 🙂

claudiu12:10:23

@ben735 For the example you mentioned this seems what you're looking for http://book.fulcrologic.com/#_combining_routing_with_data_management

claudiu12:10:05

https://gist.github.com/claudiu-apetrei/57ed1bd4e681e6466a93b98cd0e4c133 Hacked together what you mentioned.... code needs cleanup but hope it helps

Sturm22:10:58

@claudiu wow, thank you! That's very thougtful of you

Sturm02:10:23

@claudiu thanks again, I've just worked through it and your code was super-useful. Much appreciated!

hmaurer11:10:10

@tony.kay do you have any thoughts on integrating Suspense with Fulcro’s data fetching story once it gets officially release?

thheller11:10:03

is Suspense finally out? lets see what a mess they created .. throwing Promises looked so ugly the last time I checked 😛

hmaurer12:10:21

It’s not out yet, but the latest release includes a feature (React.lazy) relying on suspense. It should be out soon-ish

hmaurer12:10:36

And yes, throwing promises is ugly 😄 but it seems like it’s the only way to get coroutine in javascript

claudiu11:10:21

what is Suspense, any links ? 😅

tony.kay14:10:05

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

tony.kay15:10:53

(and hide js-ugliness if I can 🙂 )

tony.kay15:10:52

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

tony.kay15:10:05

and OMG is that ugly (looking at Suspense examples)

tony.kay15:10:12

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

thheller15:10:14

yeah I don't get that part either

thheller15:10:25

it used to be render(data) => view

thheller15:10:34

now its stateful promises everywhere even without the throw part

tony.kay15:10:09

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.

thheller15:10:58

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

tony.kay15:10:28

and OMG this sounds like a great idea from the 90's: “suddenly calling AJAX requests inside render will become OK”

thheller15:10:30

ie. instead of displaying "Loading ..." right away you can now opt to wait for a result

thheller15:10:44

so that is neat just the implementation is straight up weird

thheller15:10:48

loading spinners suck

tony.kay15:10:23

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

tony.kay15:10:51

but that is a really easy problem to solve other ways

thheller15:10:30

not sooo simple really

thheller15:10:02

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

tony.kay15:10:06

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

tony.kay15:10:25

some kind of “deferred” load marker

tony.kay15:10:31

just had never occurred to me

thheller15:10:40

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

thheller15:10:52

not for your own fulcro app

thheller15:10:24

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

tony.kay15:10:40

time to port to an alt dom diffing lib? 😜

tony.kay15:10:01

kidding…I like access to general react lib ecosystem

thheller15:10:34

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

tony.kay15:10:22

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.

thheller15:10:24

this is not a world I want to live in 😉

thheller15:10:05

yeah agreed

tony.kay15:10:12

higher-order CRAP

tony.kay15:10:34

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

thheller15:10:14

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

thheller15:10:33

its fine until you look too close 😉

tony.kay15:10:52

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

tony.kay15:10:09

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

thheller15:10:21

yeah agreed

tony.kay15:10:23

often the diff between life and death

thheller15:10:31

just wondering if Suspense really is the solution to those problems

tony.kay15:10:04

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

thheller15:10:06

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

tony.kay15:10:26

just the demo

thheller15:10:03

yeah thats still missing

thheller15:10:22

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

tony.kay15:10:27

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

thheller16:10:01

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

thheller16:10:08

the components shouldn't have to worry about it

tony.kay16:10:23

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

tony.kay16:10:50

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

sundarj16:10:54

requestIdleCallback

tony.kay16:10:04

but you have not gone idle

tony.kay16:10:29

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

tony.kay16:10:34

that’s the trick

tony.kay16:10:56

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

thheller16:10:31

well not really imho

thheller16:10:28

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

thheller16:10:42

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

tony.kay16:10:10

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”

tony.kay16:10:56

I think they basically wrote their own thread scheduling library

tony.kay16:10:15

and instead of calling them “green threads” (showing my age here), they chose “fibers”

tony.kay16:10:25

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

tony.kay16:10:02

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

tony.kay16:10:32

The async nature probably requires that you use with-parent-context for any content wrapped in async blocks

tony.kay16:10:48

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.

tony.kay16:10:17

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

tony.kay16:10:59

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

tony.kay16:10:17

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.

hmaurer18:10:28

@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

hmaurer18:10:26

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

hmaurer18:10:50

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

claudiu18:10:48

think this is a job for a smart router. if you want this custom logic. got something like this built with fulcro

hmaurer18:10:30

@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

tony.kay18:10:26

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

hmaurer18:10:33

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…

tony.kay19:10:02

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.

tony.kay19:10:26

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.

pvillegas1220:10:17

Trying to find an example of testing mutations with fulcro, anybody has a good example spec?

pvillegas1220:10:52

(Normally I test the mutation* functions, but in this case I have a mutation that delegates to integrate-ident* so want to test that)

currentoor21:10:17

@pvillegas12 you could make a function wrap the call to integrate-ident* and test that?

pvillegas1221:10:17

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)

currentoor21:10:38

well that approach does work in general for unit testing mutations, but i see what you mean

currentoor21:10:53

mutations do implement a multimethod

currentoor21:10:19

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

currentoor21:10:30

and it calls the underlying multimethod

currentoor21:10:34

which returns an action

currentoor21:10:48

then invoked that action

currentoor21:10:22

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

currentoor21:10:25

does that make sense?

pvillegas1221:10:19

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

currentoor21:10:21

the multimethod is called fulcro.client.mutations/mutate

currentoor21:10:44

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

currentoor21:10:47

give me a minute

pvillegas1221:10:57

thanks 🙂

currentoor21:10:51

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

currentoor21:10:57

don’t want to give you broken code 😅

currentoor21:10:08

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

currentoor21:10:33

defmutation is just a cleaner way to wrap a multimethod

currentoor21:10:01

let me know if anything doesn’t make sense

currentoor21:10:51

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

hmaurer23:10:18

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?