Fork me on GitHub
#fulcro
<
2019-10-28
>
tony.kay00:10:53

@thheller The app ns has refresh…you can use force-root-render! or schedule-render!

tony.kay00:10:46

the latter is usu preferred

tony.kay00:10:16

the prior will ignore optimizations, and is good for things like locale change where the props have not changed, but you want UI to completely refresh..also hot code reload

tony.kay00:10:39

schedule-render! is debounced on requestAnimationFrame

tony.kay00:10:27

(ignores addl request until a scheduled render has happened)

thheller07:10:19

@tony.kay I don't need a full app refresh though. I know that I only changed one ident?

mping08:10:50

Hi all, I'm having issues running fulcro-inspect locally : CompilerException: java.lang.RuntimeException: Unable to resolve symbol: read+string in this context, compiling:(shadow/cljs/devtools/server/repl_system/clojure.clj:113:32)

mping08:10:11

I just want a fulcro electron template to play around, so I thought it was a good idea to fork the inspect electron app

mping08:10:24

I'm running > npm run dev-electron

thheller08:10:40

@mping Clojure 1.10+ is required, read+string wasn't available in older versions

twicebaked14:10:00

Is it possible to do a recursive union query? I'm probably just tired and missing some obvious syntax. I can do either easily, it's just an issue of trying to combine both on a single set of items in a tree where each node can have children of different types with different data to fetch within the same set of children. I don't control the data but I've thought of plenty of workarounds. Hand-rolling things works, but of course since it's a tree, that doesn't help me much with arbitrary depth and the requirement that I need to load the entire tree at once. Mostly I've thought transforming the data in some other way inside a resolver might be the way to go since I can probably break things down into a much faster fetch this way, but I'm still curious if a recursive union is feasible for future reference.

tony.kay14:10:58

@twicebaked current implementation: no. Theoretically possible to extend the implementation: not sure…don’t have brain cycles at the moment to even consider how that would work.

twicebaked14:10:17

tbf I expect it would perform awful anyway 😆

twicebaked14:10:56

I just had one of those moments contemplating whether or not I am missing something and/or brain dead about the problem, so good to know.