Fork me on GitHub

regarding form state, is there a way to tell fulcro NOT to take a field (a keyword) as subform?


@U0CKQ19AQ can you help with this?


Hey, so I’m not sure what you mean. If you don’t list something in the declaration of form fields, then it isn’t used…If it’s a join to a component, then it needs to be a sub-form or it can’t be managed properly.


well, I'm building the tag editor part of an article editor. The query of the form component looks like this

[:article/id :article/title/body
 {:article/tags [:tag/tag]}


but isn’t there a Tag component that you get-query from?


for :tag/tag


but it doesn't have an ident b/c they're just strings. Also, I want the form component to treat those tags as a single vector


So, I don’t know if I’ve tested doing this, but you could make :tags a prop (NOT a join) and just treat the array of strings as an opaque value


so after I manipulate that vector, I can push update (to remote server) the article item with those tags as a whole


the diff support might not work with that, though…


but it might…worth a try. i.e. query is just [... :article/tags] without the join


hmm, walkable doesn't support such "prop that actually is a join to another table" yet 😄


let's see if I can change the query of the editor form's parent component


walkable is using pathom…wonder if you can just add a resolver somehow


a plain pathom resolver will result in inablity to use such join in sever side filters (in this case, filter articles by their tags)


why not just use a different name in the pathom resolver?


not perfect, but possibly doable


yup, possible, I just don't want inconsistence where I write queries one way and filters another


anyway, I've planned to solve that problem with walkable, just haven't touched it


for now, I'd stick to change the fulcro load


thanks for your time


But I think it would be great if form state can help with managing pristine state of data structure, too


The older form support probably can, since you can declare what is a sub-form explicitly, and which are “fields”…and you can also declare custom field types.


The join issue with the newer form support is an interesting use-case.


not sure that design can deal with that. It’s part of the reason that I didn’t deprecate the old forms support. It is a bit heavier overall, but it also does things that the newer support doesn’t. I dislike having two, but I have not had time to unify the useful things, and I don’t think we’ve had enough heavy use of the forms to enable us a good idea of what is missing.


indeed. Even when the join target does have its own ident, there are cases where you want to keep track of the whole list of idents (some of which can still be tempids) and send off to remote in a single transaction. I will think more about this


I want to use some nested Clojure data structure as the field's value while having fulcro manage its pristine state. Its query is a join, but the join target doesn't have its own ident.


what does "Older Support" in "Full Form Management (Older Support)" mean? Is it no longer recommended?



The form state support concentrates just on providing utilities to manage the data, and has validation that is based on Clojure Spec but is completely pluggable. The full form management support is the older version that attempts to isolate your components a bit more from the event and state management, but at the expense of some added complexity.

Both are fully supported, though the form state support is considered the cleaner implementation.

👍 4

I have added html5 routing following example in fulcro routing video (which uses bidi/push). Have top-level routing w/o parameters working. Just now adding params and getting

Uncaught Error: No protocol method ParameterEncoding.encode-parameter defined for type object: 57346128458562730
The id is a datomic entity id. Pointers welcome.


Evidently bidi didn’t like the long - so converting to string worked. Looking more closely at the bidi docs re: parameter matching.