Fork me on GitHub
#fulcro
<
2018-01-27
>
wilkerlucio01:01:45

@thosmos I just released [fulcro-inspect "2.0.0-alpha5"], this should fix the issues on start, can you please verify?

thosmos08:01:01

yes, no errors đź‘Ť

thosmos22:02:26

I just upgraded an app based on fulcro-template 1.x to 2.x and am now getting 6 of the following errors:

[ 11.504s] [fulcro.client.impl.application] Mutation  fulcro.inspect.ui.transactions/add-tx  failed with exception Error: Assert failed: Path [:fulcro.inspect.ui.transactions/tx-list-id [:fulcro.inspect.core/app-id rimdb-ui.ui.root/Root] :fulcro.inspect.ui.transactions/tx-list] for append must target an app-state vector.
(vector? (get-in state data-path))

thosmos22:02:03

and that is using [fulcro-inspect "2.0.0-alpha5"]

thosmos22:02:34

seems to work fine though

tony.kay19:01:35

Updated lein template. The shadow-cljs project option now uses newer versions, and enables HUD by default. Very nice experience, I think. lein new fulcro app-name shadow-cljs

denik17:01:20

(this is general point about templates) @tony.kay with templates we throw away version control. the path to transition for everyone who used a given template from on version to the next is copy and paste. users also have to maintain the boilerplate of the template. if it was a library instead, the change could be an update in a version number + optionally a tweak in a config file.

tony.kay17:01:55

Not sure what you’re asking. There is a github fulcro-template that you can clone (with history). The problem there is providing options. I’ve decided to lean more towards treating templates like a pure starting point. Once you’ve type “new”, it’s yours to evolve however you see fit.

denik18:01:29

Sure, but is that good for your users? In a project that’s growing as fast as fulcro, including the growth of shadow-cljs, it doesn’t scale when all your users need to manually maintain their boilerplate and add deps every time a new feature lands.

tony.kay18:01:10

Feel free to suggest a specific solution, code it up, and send a PR. I’m currently doing what I can with the time I have. I don’t see how “updating a version” or “tweaking a config” doesn’t scale for users any worse than “fixing merge conflicts” from changes you didn’t make.

tony.kay18:01:25

I really don’t think there is a great solution…things change, and I don’t see a way to make it substantially easier. I’ve tried it all of the ways I can think of, and over time, it just doesn’t seem to matter.

tony.kay18:01:34

I guess perhaps I don’t know what you mean by a “library”. Do you mean like I’ve done with fulcro-template (the non-lein template)?

denik18:01:39

Will do. I’m working on a project to show the difference. What I mean by library, is something you don’t generate or clone but use (add it to your build.boot / project.clj). The author can change a library to improve all users’ experience without requiring them to take any action. This way long lived projects become updatable instead of a copy & paste mess. Anyway @tony.kay please don’t take this personally and thanks for the effort you put into clj/s tooling and fulco

tony.kay18:01:26

Not taking anything personally 🙂 Just trying to see your proposed solution.

tony.kay18:01:04

Requirements include: dev, runtime, uberjar generation, CI testing (client and server), dev-time use of fulcro-spec in browsers for client and server. I guess you could sorta make lein/boot plugins in a library, but that seems painful to maintain and get working.

tony.kay18:01:20

oh, and devcards support

tony.kay18:01:22

and most users will need to customize a lot of that based on their needs. If you’ve got the cycles to figure out something better, happy to see it and promote it!

denik19:01:24

I think all you need is the repl. I now have a prototype that installs node-modules, shadow-cljs for dev, and index.html file, starts an http server with custom routes and much more after just calling a simple dev-start function from my library. It’s easy to see how this could be extended to provide CI files, and even augment the project.clj, deps.edn files if necessary. A config must be passed in by the user, on a breaking version change, the library can explain exactly which keyvals are wrong/missing, etc. Currently just building a prototype for myself. If it pays of, I’ll share my findings here.

tony.kay20:01:37

Hey, sounds great!

tony.kay19:01:43

I also have almost completed the new form-state support, and would be interested in hearing from anyone that would like to review it before release. The support is on github on the feature/form2 branch (in the fulcro.ui.form-state namespace, with budding docs in a devcard in the cards build). The basic idea is to strip forms support down to state management (still supporting subforms) and normalize the pristine state tracking so it doesn’t clutter your entities as much. I think it’s an improvement and simplification of the current forms support. At the moment the validation support uses spec. I may still generalize that to be pluggable…in fact, it sort of already is, but I’d have to document it. The core features are: - Tracking a pristine copy of the original - Generating a delta when the form has changed (for you to be able to submit a minimal delta), including subforms and relations - Tracking which fields have been tested for validation - Giving you a way to “walk/transform” the form set to add your own support routines on top - Helpers for “reset” (copy pristine back over top of the entities) and “save” (modified entity copied to pristine)

denik17:01:20

(this is general point about templates) @tony.kay with templates we throw away version control. the path to transition for everyone who used a given template from on version to the next is copy and paste. users also have to maintain the boilerplate of the template. if it was a library instead, the change could be an update in a version number + optionally a tweak in a config file.