I am not sure I can test if an om component implements a protocol in Clojure (asked in #om too). So this line is blocking me right now: https://github.com/untangled-web/om-css/blob/master/src/om_css/core.cljc#L67
So defui in clj land adds the "protocol" things to metadata
just a sec...
https://github.com/untangled-web/untangled-client/blob/develop/src/untangled/client/core.cljc#L84
this is why we need functions like get-initial-state
. We can call the protocol ones in cljs, but not in clj because js allows his macro to hack them into place
Om components have to be stock React components for interop, so we don't actually use protocols per-se, just emulate the syntax
this is part of the cleanup work that we need to comb over in a lot of our docs/guide for sever-side rendering. You cannot, for example, call initial-state
in your UI and expect clj-land to like it
but many of our examples were written before it existed, and are now technically wrong if you want to do ss rendering
Ok that all makes sense. So I don’t have the metadata “protocol” with plain om.next components, right (I did have a look at meta in my Repl).
I just aped what was in Om's get-query
code 😉
since that one has to work on both
ok I’ll have to dig a bit more (just starting with om 😛 ) thanks for the help!
sure
Just FYI on the forms support in ui: I'm touching up the full-stack protocol. It was a little too loose.
i.e.: the network communication that is there is changing
Hi Tony, I’m using the forms support right now. Are any breaking changes expected?
@baris Yes, but not at the UI level.
The protocol that got written for telling the server what changed is a little off and unclear
I had not code reviewed it, but am now writing the docs. It is technically working, but harder to reason about and use than it should be
ahh good to know....I’m in a couple minutes ready to touch the server side....good to know…I’ll wait then
Yeah, I should have spec'd this better for the person that wrote it. Like I said, it technically works, just isn't ideal.
so far its works like expected and the form support is really handy 👍
Yeah, I've messed with the UI layer enough that it is pretty solid. The full-stack stuff I loosely spec'd and got help for. The spec was too loose 🙂
I got the following strange use-case: 1) User starts editing an entity (like described in the demo devcard) -> forms show up 2) User makes some changes and the local app-state changes imediatly -> form is dirty 3a) User can revert the changes by clicking the "reset" button -> OK 3b) User commits the changes by clicking the "save" button -> OK 3c) User changes the screens for e.g. by clicking on another top navigation link -> form should reset but it saves the local changes
The confusing part is 3c. I'd expect even if I made some changes and I switch to another view (like cancel the current modifications) I'd expect that the changes do not get into the local app state.
The forms component already stores the original values in the an isolated :origin {...}
map and only
uses them when the "reset-*" functions are called. Maybe we should switch the logic here?
Store all local changes to a local isolated place and copy them to the orignal "entity" when save/commit is called?
For now, I do some workaround while switching the screens and it works so far for me.
So, we debated this at some length internally.
Here is the reason why it works that way:
1. You can always compose reset into any mutation. So, nav without save can undo the changes
2. We want you to be able to render just like you always have, and subforms throws a wrench in that if you make the stuff you're editing sideband
Regarding form validation in untangled-ui, are there any plans for extending field validation checks returning more than a boolean?
@torkan You're missing the point. Validation is for marking state in the tri-state system: :unchecked, :valid, :invalid. Boolean is all that is needed.
The messaging is up to you in rendering
@baris On (2), I can give you a more detailed example if you'd like
@baris This line of code: https://github.com/untangled-web/untangled-ui/blob/develop/src/guide/untangled/ui/forms_overview_cards.cljs#L300
My workaround is ur number 1: I reset them manually when a nav mutation happens
that isn't a workaround
that is the way to do it 🙂
@tony.kay Wouldn’t be the first time 🙂 I haven’t fine-combed through all the code yet, but it seems like there are no ways to determine why a field was deemed invalid?
perfect 🙂
@torkan So, you can look at the value they've typed at the UI layer
validation is about signalling. Messaging is about interpretation of value
The latter is your responsibility in the UI
forms support does state management, and all it cares about is that the field is "ok"
If you're worried about code re-use: write a single function that returns nil when all is OK, and call that with not
in your custom validator, then use the same function to generate the message on the UI
Gotcha… I’m asking since a field might be technically valid in terms of conforming to a value range/regex etc, but business logic might still deem it as invalid, perhaps depending on values in other fields, and so forth…
Some of that can only be handled with on-form-change
non-local reasoning about fields, that is
Redux-Form for example solves this by letting you pass methods for validating the form, and returning error-values for the fields that failed
so we have both
The form-level handling is a single function that can do anything to the form (change validation flags etc)
the field-level validation is just about reasonable values
Aaah, I totally missed that 🙂
you could put the entire validation in the top-level one instead
it isn't documented yet 😉
and I have not code reviewed it, so it could change slightly
The way it currently works is you can add a mutation symbol to the form support that it will trigger any time it detects a change in the form...I have not reviewed when it gets triggered, so I'm not sure what "detects a change" means at the moment 🙂
that mutation can do whatever it deems necessary
Nice
So, at the moment, it triggers on each change (e.g. keypress/selection)
Seems like blur might be a better choice on input fields
or perhaps the mutation should just be told what kind of change it is
yeah, that needs to evolve a little
the concept is solid, just needs execution tweaks
Blur is a sensible default, as long as it can be overridden, at least in my opinion
need both
but blur will be most common of interest
you might want to do tricky things like insert format chars...e.g. typing a cc number and auto-add dashes
possibly, I guess
might also just use comp local state for that kind of concern and a custom field type
Yup, an error indicating that a new password the user is setting is too short for example, should disappear immediately
Once the password gets strong enough, etc
yeah