I have been working through the fulco video tutorials and really enjoying them. Thanks for doing that @tony.kay

good to hear. Thanks for letting me know

Just added docs on the function-as-a-child react interop to the developer’s guide: http://book.fulcrologic.com/#_the_function_as_a_child_pattern

Thanks @levitanong for pointing out this interop problem and solution.

:D my pleasure @tony.kay

Thank you @levitanong been bitten by that once, but never realized the problem

I'm just starting to read on Fulcro, so forgive me if this is a dumb question. Is the backend server something lightweight enough to run as an AWS lambda function, or does it need a dedicated server/container?

@d4hines The back-end can be completely up to you. The provided server options are a very thin Ring stack

look in the dev guide under “Rolling your own” server

@tony.kay Ah, ok. I missed that section in my quick skim of the docs. Thank you! Also, I want to echo drewverlee's comment - the video guides are awesome, and I can tell you've put a lot of time, thought, and work into this whole thing.

always time…usually thought 😜

@d4hines I'm planning to release soon a tutorial on how to use graphql endpoints directly from the fulcro client, this way you can use services like graph.cool and avoid writing the server side entirely

@wilkerlucio That sounds awesome - I look forward to it! Is there somewhere I should subscribe to get such tutorials?

@d4hines not an specific place, I'll probably be posting here, it's going to be part of pathom documentation: https://wilkerlucio.github.io/pathom-book/DevelopersGuide.html

@wilkerlucio Ok, thanks!

Is it possible to pass down local-component state from a parent to a child component? It seems when I do it it doesn't work if that data is not also part of the child component's query. If I log out props of the child component it seems to only populate props based on its query. And if I put it in the computed-data it's just nil. The only place I can see the prop seems to be in next-props in componentWillReceiveProps. I can make it work by putting this state in the store but it's just ui-related (currently-active item) and would rather not mix it with the data of the rest of the application.

computed is for that

the 3rd argument (optional) of defsc is how you receive computed, or you can call (prim/get-computed this)

(defsc X [this props computed-stuff]
   ...)

@pontus.colliander ^^^

UI-related stuff that you want history on should be placed in the query and props. The namespace(s) starting with a ui segment won’t participate in full-stack interactions

So, if you want history support viewer or error handling via time travel, or any history-related features you should consider putting them in app state….but if it is speed-related (e.g. animation) stuff, computed and component local state are fine.

Thanks for the answer, it cleared it up 🙂