Clojurians Log v2

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