Fork me on GitHub
#fulcro
<
2021-10-18
>
futuro15:10:04

Is the Chrome plugin still the recommended method of debugging fulcro apps, or is there support for Firefox/a standalone electron app?

tony.kay16:10:13

I use chrome, so I guarantee it is the most well-tested. That said, there is a standalone Electron app that is using most of the same code. I do not have time to maintain more.

futuro16:10:15

:thumbsup::skin-tone-2: Sounds good, thank you.

futuro16:10:51

I've got a take home code challenge involving a frontend, and I wanted to give Fulcro a go for solving it, so re-acquainting myself with different parts of it.

tony.kay16:10:54

@holyjak Something that comes up on occasion, and I realize isn't particularly well-documented, is the case where you actually want to use some predefined lambda as a callback in Fulcro. I generally discourage the practice when possible, but there are definitely use-cases where it is really useful and is the best way to accomplish something. I've added something to the docstring of transact about it, and load already had it in the docstring, but it might be a good thing to add to what you're building. The most common case I see it being useful is when making generalized components that have some I/O, but are not pre-tied to something in the application. I've generally encouraged the use of mutations for such things because they have a well-defined semantics and show up in the dev tooling, but sometimes you already have a function that is exactly what you want, and you'd just like to trigger it without making a whole new mutation. In transact! you can do it with the options map. Anything you put in there is safe (js objects, fns, etc.) and shows up in env of all mutations of that transaction as ::txn/options. For load, it's post-action.

👀 2
😸 1
tony.kay22:10:18

A note on RAD: I just spent some time fixing up the date/time support. The library was created when js-joda and cljc-java-time were a bit in flux. I also slimmed down what RAD itself requires. This means that you must require your own locale support if you use the datetimeformatter stuff (mainly the human-readable-date function in date-time). I've updated the demo to show that in the client.cljs file. This is technically not a breaking change in RAD, but if you don't get the deps right it can be a breaking change for your app. RAD version 1.0.29 The main changes are to what you should require from js-joda and that you should set your own locale if you want that support. See these two files from the demo: https://github.com/fulcrologic/fulcro-rad-demo/blob/develop/package.json#L18 lines 18-20. You don't need 20 if you don't want DateTimeFormatter stuff to work https://github.com/fulcrologic/fulcro-rad-demo/blob/develop/src/shared/com/example/client.cljs#L3 lines 3 and 50. Basically require the locale stuff, and set yours on startup

👏 4
roklenarcic08:10:30

So in normal fulcro app, the backend returns date/time as java.util.Date and the frontend uses this js-joda for formatting/parsing?

tony.kay14:10:39

yeah. I'm not happy with this release, actually. js-joda doesn't handle locales and such to my satisfaction. I'm actually going to be reverting this change, and trying a different approach. It's been js-joda all along, but that library was in flux when I build RAD, and the locale support still isn't ideal for my use. I think the built-in browser support can be made to work, but it's been a bit of a challenge to navigate requirements with available features.