was about to ask about the best way to setup components on devcards, in terms of properly rooting them, etc to test mutations. but looks like @wilkerlucio and co's workspaces already address this? By default the Fulcro card will wrap your component will a thin root, by having always having components with idents you can leverage generic mutations, this is recommended over making a special Root.

yes, it does, and it also injects the CSS in a sane way for you 😉

oba! 🙂 thanks

working on getting it setup

given all the fulcro integration and goodies

you guys think this will be the defualt in the templates going forward

?

@wilkerlucio i've set stuff up. but for some reason, the workspaces.html i've setup, is loading my app

@eoliphant not sure what that means, you mean opening your html instead of the workspaces one?

yeah I basically, just added all of the workspaces bits. a workspaces build in shadow-cljs on a new port, a new workspaces.html ugh nevermind lol. I misspelled 'workspaces.html' and I guess shadow defaulted to serving index.html

though @wilkerlucio I'm having another, perhaps actual, issue 😉 I'm getting a 'no app connected' in the fulcro-inspect window with workspaces open, even after tapping on the 'inspector' button I've upgraded to 1.0.6 of the extension, and 2.2.4 for the dep, and it still works fine on other fulcro apps. No errors or anything in the console

thats odd, the shadow config has the preload for it?

ah, that's it i think. I just copied the config from the readme.

working fine now thx

ok.. yeah this is pretty awesome. next time i'm in Sampa, I'm buying you a drink 🙂

Has anyone written something to go through devcards and screenshot their content (i.e. using headless chrome)? I could write it myself but curious if it has been done

@hmaurer yes i have

but it was closed source

ah 😞

but we have a gist

https://medium.com/adstage-engineering/how-we-test-our-full-stack-clojure-app-b18d79ee9e00

in the section on visual regression tests

https://gist.github.com/adstage-david/864539c452f9fa54851bab09a40f09fb

that gist has all the useful bits

Oh great, thank you! Taking a look now

do you store “good states” in a database or something?

ah no, in files, I see

yeah we just stored the good states in the git repo

git was our database lol

@tony.kay I noticed something here, when I do a load and it fails at network level, the load marker set in the request stays in :loading state, I guess it should move to :failed, or am I missing something?

correct, that sounds like a bug

ok, I think we have a bug then 🙂

I just added a security chapter to the book, released a normal and websockets security demo, and released Fulcro 2.6.8 with some small added helpers that people can use in their own code.

http://book.fulcrologic.com/#Security

If you’re using Fulcro in production, you should probably have a look. If you’ve already secured your Fulcro app and have additional suggestions, please let me know.

Quick question @tony.kay: I think you mentioned retries aren’t implemented for the HTTP transport (but are for the websocket transport). How much work for it be to implement them for the HTTP transport?

you should be able to make a little wrapper remote…probably a few lines of code

the HTTPRemote protocol in Fulcro has a send method…you’d make one of those that takes a real remote and proxies calls to send…and then you’d hack into the error callback and retry on network errors instead of calling the real error callback