untangled

NEW CHANNEL: #fulcro
2017-02-20T18:01:38.003527Z

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

tony.kay 2017-02-20T18:02:33.003530Z

So defui in clj land adds the "protocol" things to metadata

tony.kay 2017-02-20T18:02:40.003531Z

just a sec...

tony.kay 2017-02-20T18:04:07.003534Z

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

tony.kay 2017-02-20T18:04:41.003535Z

Om components have to be stock React components for interop, so we don't actually use protocols per-se, just emulate the syntax

tony.kay 2017-02-20T18:05:42.003536Z

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

tony.kay 2017-02-20T18:06:08.003537Z

but many of our examples were written before it existed, and are now technically wrong if you want to do ss rendering

2017-02-20T18:07:20.003538Z

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).

tony.kay 2017-02-20T18:08:29.003541Z

I just aped what was in Om's get-query code 😉

tony.kay 2017-02-20T18:08:45.003542Z

since that one has to work on both

2017-02-20T18:09:21.003543Z

ok I’ll have to dig a bit more (just starting with om 😛 ) thanks for the help!

tony.kay 2017-02-20T18:12:42.003544Z

sure

tony.kay 2017-02-20T18:29:05.003545Z

Just FYI on the forms support in ui: I'm touching up the full-stack protocol. It was a little too loose.

tony.kay 2017-02-20T18:29:24.003546Z

i.e.: the network communication that is there is changing

2017-02-20T19:04:10.003547Z

Hi Tony, I’m using the forms support right now. Are any breaking changes expected?

tony.kay 2017-02-20T19:05:32.003548Z

@baris Yes, but not at the UI level.

tony.kay 2017-02-20T19:06:02.003549Z

The protocol that got written for telling the server what changed is a little off and unclear

tony.kay 2017-02-20T19:06:36.003550Z

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

2017-02-20T19:06:53.003551Z

ahh good to know....I’m in a couple minutes ready to touch the server side....good to know…I’ll wait then

tony.kay 2017-02-20T19:07:31.003553Z

Yeah, I should have spec'd this better for the person that wrote it. Like I said, it technically works, just isn't ideal.

2017-02-20T19:08:10.003554Z

so far its works like expected and the form support is really handy 👍

tony.kay 2017-02-20T19:09:13.003555Z

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 🙂

2017-02-20T19:28:46.003556Z

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

2017-02-20T19:28:51.003557Z

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.

2017-02-20T19:28:57.003558Z

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?

2017-02-20T19:29:01.003559Z

Store all local changes to a local isolated place and copy them to the orignal "entity" when save/commit is called?

2017-02-20T19:29:05.003560Z

For now, I do some workaround while switching the screens and it works so far for me.

tony.kay 2017-02-20T19:29:42.003561Z

So, we debated this at some length internally.

tony.kay 2017-02-20T19:29:50.003562Z

Here is the reason why it works that way:

tony.kay 2017-02-20T19:30:09.003563Z

1. You can always compose reset into any mutation. So, nav without save can undo the changes

tony.kay 2017-02-20T19:30:40.003564Z

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

torkan 2017-02-20T19:30:53.003565Z

Regarding form validation in untangled-ui, are there any plans for extending field validation checks returning more than a boolean?

tony.kay 2017-02-20T19:31:41.003567Z

@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.

tony.kay 2017-02-20T19:31:47.003569Z

The messaging is up to you in rendering

tony.kay 2017-02-20T19:32:12.003570Z

@baris On (2), I can give you a more detailed example if you'd like

2017-02-20T19:33:59.003573Z

My workaround is ur number 1: I reset them manually when a nav mutation happens

tony.kay 2017-02-20T19:34:08.003574Z

that isn't a workaround

tony.kay 2017-02-20T19:34:14.003575Z

that is the way to do it 🙂

torkan 2017-02-20T19:34:16.003576Z

@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?

2017-02-20T19:34:20.003577Z

perfect 🙂

tony.kay 2017-02-20T19:35:08.003578Z

@torkan So, you can look at the value they've typed at the UI layer

tony.kay 2017-02-20T19:35:21.003579Z

validation is about signalling. Messaging is about interpretation of value

tony.kay 2017-02-20T19:35:35.003580Z

The latter is your responsibility in the UI

tony.kay 2017-02-20T19:36:01.003581Z

forms support does state management, and all it cares about is that the field is "ok"

tony.kay 2017-02-20T19:37:19.003582Z

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

torkan 2017-02-20T19:38:34.003583Z

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…

tony.kay 2017-02-20T19:38:57.003584Z

Some of that can only be handled with on-form-change

tony.kay 2017-02-20T19:39:18.003585Z

non-local reasoning about fields, that is

torkan 2017-02-20T19:40:27.003586Z

Redux-Form for example solves this by letting you pass methods for validating the form, and returning error-values for the fields that failed

tony.kay 2017-02-20T19:40:45.003587Z

so we have both

tony.kay 2017-02-20T19:41:08.003588Z

The form-level handling is a single function that can do anything to the form (change validation flags etc)

tony.kay 2017-02-20T19:41:20.003589Z

the field-level validation is just about reasonable values

torkan 2017-02-20T19:41:27.003590Z

Aaah, I totally missed that 🙂

tony.kay 2017-02-20T19:41:28.003591Z

you could put the entire validation in the top-level one instead

tony.kay 2017-02-20T19:41:35.003592Z

it isn't documented yet 😉

tony.kay 2017-02-20T19:41:48.003593Z

and I have not code reviewed it, so it could change slightly

tony.kay 2017-02-20T19:42:59.003594Z

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 🙂

tony.kay 2017-02-20T19:43:12.003595Z

that mutation can do whatever it deems necessary

torkan 2017-02-20T19:43:32.003596Z

Nice

tony.kay 2017-02-20T19:44:26.003597Z

So, at the moment, it triggers on each change (e.g. keypress/selection)

tony.kay 2017-02-20T19:44:40.003598Z

Seems like blur might be a better choice on input fields

tony.kay 2017-02-20T19:44:53.003599Z

or perhaps the mutation should just be told what kind of change it is

tony.kay 2017-02-20T19:45:00.003600Z

yeah, that needs to evolve a little

tony.kay 2017-02-20T19:45:13.003601Z

the concept is solid, just needs execution tweaks

torkan 2017-02-20T19:47:09.003602Z

Blur is a sensible default, as long as it can be overridden, at least in my opinion

tony.kay 2017-02-20T19:47:14.003603Z

need both

tony.kay 2017-02-20T19:47:26.003604Z

but blur will be most common of interest

tony.kay 2017-02-20T19:48:02.003605Z

you might want to do tricky things like insert format chars...e.g. typing a cc number and auto-add dashes

tony.kay 2017-02-20T19:48:11.003606Z

possibly, I guess

tony.kay 2017-02-20T19:48:24.003607Z

might also just use comp local state for that kind of concern and a custom field type

torkan 2017-02-20T19:48:26.003608Z

Yup, an error indicating that a new password the user is setting is too short for example, should disappear immediately

torkan 2017-02-20T19:48:59.003610Z

Once the password gets strong enough, etc

tony.kay 2017-02-20T19:49:05.003611Z

yeah