This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-02-20
Channels
- # aleph (19)
- # aws-lambda (8)
- # bangalore-clj (1)
- # beginners (13)
- # boot (179)
- # cljs-dev (12)
- # cljsjs (2)
- # cljsrn (6)
- # clojure (174)
- # clojure-italy (14)
- # clojure-nl (2)
- # clojure-russia (172)
- # clojure-spec (29)
- # clojure-uk (22)
- # clojurebridge (10)
- # clojureremote (1)
- # clojurescript (79)
- # cursive (46)
- # data-science (1)
- # datascript (8)
- # datomic (18)
- # defnpodcast (2)
- # emacs (9)
- # events (6)
- # hoplon (11)
- # klipse (13)
- # lein-figwheel (1)
- # leiningen (1)
- # luminus (1)
- # lumo (88)
- # numerical-computing (1)
- # off-topic (24)
- # om (33)
- # onyx (58)
- # protorepl (8)
- # re-frame (10)
- # reagent (26)
- # ring (8)
- # ring-swagger (7)
- # rum (22)
- # spacemacs (25)
- # specter (5)
- # uncomplicate (37)
- # untangled (75)
- # vim (17)
- # yada (3)
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
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).
Just FYI on the forms support in ui: I'm touching up the full-stack protocol. It was a little too loose.
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.
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?
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.
@baris This line of code: https://github.com/untangled-web/untangled-ui/blob/develop/src/guide/untangled/ui/forms_overview_cards.cljs#L300
@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?
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…
Redux-Form for example solves this by letting you pass methods for validating the form, and returning error-values for the fields that failed
The form-level handling is a single function that can do anything to the form (change validation flags etc)
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 🙂
you might want to do tricky things like insert format chars...e.g. typing a cc number and auto-add dashes
might also just use comp local state for that kind of concern and a custom field type