This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-05
Channels
- # announcements (13)
- # aws (1)
- # bangalore-clj (4)
- # beginners (66)
- # boot (11)
- # calva (27)
- # cider (27)
- # clj-kondo (76)
- # cljdoc (6)
- # cljs-dev (38)
- # clojars (3)
- # clojure (143)
- # clojure-dev (2)
- # clojure-europe (6)
- # clojure-greece (10)
- # clojure-italy (10)
- # clojure-nl (5)
- # clojure-norway (2)
- # clojure-sweden (1)
- # clojure-uk (19)
- # clojurescript (49)
- # cursive (13)
- # datomic (14)
- # duct (6)
- # figwheel-main (3)
- # fulcro (31)
- # funcool (7)
- # jobs (3)
- # keechma (142)
- # liberator (1)
- # off-topic (15)
- # om (2)
- # reagent (1)
- # reitit (2)
- # remote-jobs (1)
- # rewrite-clj (73)
- # shadow-cljs (21)
- # spacemacs (18)
- # sql (5)
- # tools-deps (10)
- # yada (1)
The required namespace "
The required namespace "
I'm facing these two errors.
Is it correct namespace to install Forms and Dataloader?
i don't use the forms thingie, i usually have personal requirements that never fit with any library
Yeah, i added it toolbox to shadow-cljs.edn
are you sure your current selected build can see it? looks like a project level problem
I tried in repl, all namespaces are available which are documented here: https://keechma.com/api/keechma-toolbox/
But namespaces which I mentioned are giving same error in repl too.
I'm using [keechma/toolbox "0.1.6"]
i got bitten by that too @mihaelkonjevic should maybe update that page you linked
@carkh @ahmed1hsn yeah, will do. I got bitten by an old version in my deps yesterday too 😰
worst part, I had linked dev version in checkouts, so it was working locally
Thanks @carkh and @mihaelkonjevic how can I know latest versions of Keechma and keechma/forms?
you can see it on github
And does keechma/forms have to be added separately?
and on clojars
keechma toolbox depends on keechma/forms
it’s a bit weird becasue keechma/forms is developed to be used without keechma, and then keechma toolbox has alternative implementation that’s using some parts from keechma/forms but is using controllers under the hood
@carkh I’d like to hear about your personal requirements for forms. I wonder if I have solutions ready 🙂 . I was able to implement various weird requirements over the years without any problems
so, i like to have my forms work just like i want, usually that's server validation, real time reported to the client
makes sense
I used to hate forms, and wrote at least 10 different libs over the last decade, but it finally stabilized with keechma
i think it's ok to have specific per project implementation, when the time frames are as long as mine
yeah, definitely. I need a default implementation that is good enough and I put a lot of research / work in UX support - especially around the error reporting - here’s a blog post I wrote some years ago about that https://medium.com/wdstack/inline-validation-in-forms-designing-the-experience-123fb34088ce
Is [keechma "0.3.13"]
newest Keechma version?
@mihaelkonjevic i think i already did read that, and did not agree with you !
interesting, would love to hear more
it goes like this: - if field is in error state - it will validate on change (keypress) - if it’s in valid state - it will validate on blur - on submit it will validate all fields (even if they are not dirty)
what i like is debounced, timout based on change validation, always ask the server as single source of truth
the password confirm case is handled by the server to only report errors when it makes sense
In my experience at least 90% percent of validations can be performed on client (with same validations on server). The only things that require server interaction and can’t be done on client are validations that require uniqueness
yeah, but a lot of server side solutions have a problem with partial validations -> and you don’t want to show errors for stuff that user hasn’t touched yet
why then do the job twice, once you have the machinery to do real time server validation there is no overhead
so, I guess it would be possible in Clojure or with custom validation lib, but defaults (like in Rails or Phoenix) are horrible
my conclusion (so far) regarding wizards are that each page should be treated as a separate form, with persistence on the last step (maybe saving draft version without validations)
I must say that I started to consider them antipattern, but designers sure do love wizards
and then there is soooo much problems with going back, optional steps and similar
i'm in the telecom industry, adding a new professional customer to a carrier is not 3 fields and be done with it, there are equipments to add and so on
yeah that makes sense, but each wizard ends being a small app in the end
and I was recently implementing wizards with one step per page and maybe 10 - 20 fields total
which made no sense
yeah, but wizards require a blend of great ux, backend and frontend solutions. UX is actually most important here, but it also requires a lot of work from both frontend and backend to work properly. Especially if you allow people to leave wizard, go back and have optional steps. There’s no one size fits all solution, and I have a feeling that sometimes the designers are not aware of gravity of the situation 😄
i never quite formalized a good reusable wizard thing, and you never quite make enough of these in a project to really get it all nice
you can go around it by using a vector signature - so (cmd> ctx :cmd-name :payload)
will go to the default topic and (cmd> ctx [:topic :cmd-name] :payload)
can send to any controller
The reason was that I used to have much more granular controllers before dataloader, so almost each component had it’s controller
nowadays I usually have 1 controller named user-actions
for most apps
and most of the state is handled either through the loader or through the forms
but it’s not a rule, it depends on the app
the reason why you would want to do it is to be able to re-map the topic from outside
remember i had asked about state machine, i looked at your implementation, then decided to do my own, then decided behavior trees were more expressive and could do state machine, and i'm about to release a library for that.
oh nice
so i'm asking about eventing, because that's a new controller and i was wondering how i would manage another controller
What I did with forms was: - used a namespaced key for controller topic - implemented ui layer that calls cmd> under the hood, but knows the topic and format of payloads
also when you install forms, form subscriptions are added to all components
(they also use namespaced keys)
that way there is no orchestration needed before you start using forms
I usually create install function that adds everything to the app config https://github.com/keechma/keechma-toolbox/blob/master/src/cljs/keechma/toolbox/forms/app.cljs
it doesn’t really cost anything
since it just adds the key to the subscription-deps, and if you don’t deref subscriptions they are dormant
yeah, I know I’m against global deps, but convenience won here
(wasn’t an easy decision to make :D)
true, but still felt a bit dirty
forms also forced the change that allowed vector topics in commands
because I had a situation where I had a form and wasn’t able to send commands to other controllers
I’ll add it
no problem, looking forward to that lib you’re working on
I’m also working on some new stuff, but it will take some time before it’s ready for release
biggest thing I’ll release is support for something like django template blocks
ohyes that all takes so much time, already killed 3 weeks on this thing...trying different evaluation strategies and so on
layout components that can have slots where components can put content
probably not for me, i'm a simple man, with corporate customers who don't want any fancy stuff
well it’s the same principle like selmer is using (from luminus)
yeah for html
not for reagent components
it’s more about situations where you have a page that needs to “break out” from the parent component’s layout. I’ve actually recently changed how I architect apps on the UI side. I’ve started using core.match in main component, and pattern match all possible pages in the app. That way each page can decide on it’s own how it will be rendered (instead of having parent components that decide). So page wraps itself in the layout -> inversion of control, and very shallow component trees
yeah, but the problem is when you want to change things that require “wrapper” html
then each component needs to know about it
(i decided years ago against using core.match when i found a bug and it never was corrected, and couldn't do it myself because it's a pretty hard code base)
oh, I’m using it in a pretty simple way so hopefully I won’t hit it. Although now there are some alternative libs
mhh i'm sure the problem you're trying to solve is real, but i guess i never encountered it
yeah, I have a huge list of topics already, just have to find time to write about them all