Fork me on GitHub

Is it fine to run a transact within a mutation’s body with Fulcro? e.g. to follow up on a mutation with another mutation that the first mutation decides on


see ptransact!


@tony.kay ah; my understanding was that ptransact was for running mutations in a sequence, but not for the first mutation to decide on what mutations should be ran next. I’ll look into it; thanks!


@wilkerlucio Hi! I think you worked on Fulcro’s devtools? I’ve a quick question: is there a reason why the “ghost” view when you rewind the application history doesn’t fully respect the application’s styling? For example in my application the ghost view is full-width and weirdly formatted compared to my app


humm, maybe some container problem, the container element for the dom might have different properties compared to the one your app uses


Yeah that fixed my styling issue, but… while rewinding the history the app’s UI isn’t faded out at all, so I can’t see the ghost UI (since it’s super-imposed on the app’s UI), if that makes sense…


is there an easy way to configure it so that when rewinding the history the “current UI” is faded out?


no, currently no feature for that


@wilkerlucio and is there any hack that would work? some way for the app to style its root differently when rewinding the history without modifying fulcro-inspect’s source code?


nothing that I can think right now, one possible way could be inspect setting some class at the body during preview (and some class on the container so css could not target it), that could be nice if we want the user to override the default opacity as well


Yeah that’s what I thought. If the body had a class then you could easily customise whatever. I’ll look into the source code of fulcro-inspect then; thanks 🙂


I wouldn’t want to override it normally but in my case the default styling is pretty awful; I can’t see what’s going on


Also, last but not least: is there a way to see metadata on DB objects in the data viewer?


if you wanna send a PR on inspect I would be glad to take it, maybe its not a lot of things, just have to be careful to proper add/remove the body class on the appropriated times


about the last, also a desired but not implemented feature 🙂


Cool 🙂 Out of curiosity, do you use metadata on maps transacted in the DB yourself? I’ve found it useful recently to sometimes tag things with timestamps of when they were added to the DB


never used on the values, but I can see it been helpful in some cases, I have more use to meta as part of the component queries, I'm using it to setup generative configuration about the query data


ah yep that’s right, I do style my app’s container. I guess moving that syling to a div under the container would fix it? I’ll try


@wilkerlucio with regard to adding a class to body when showing the DOM history, where would you do this? In the mutation’s body here? Or in the DOMHistoryView with a React lifecycle hook? (componentDidMount / componentDidUpdate). Or elsewhere?


I think as a lifecycle will be easier to make it consistent, so you can use the componentWillUnmount to dispose it


yep; sounds good 🙂


Do you ever find yourself wanting to namespace UI attributes? e.g.. :ui.person/some-prop


@hmaurer that's totally valid and will be elided by fulcro on remote requests

👌 5

If a component doesn’t have a query, would you still pass props from the parent as computed? (and not directly as props)


no, in this case just use regular props, the point of computed is that you don't lose in case fulcro triggers a refresh there


@wilkerlucio ah! makes sense. Thanks