Clojurians Log v2

The required namespace "<http://keechma.toolbox.forms.app|keechma.toolbox.forms.app>' is not available, ...

The required namespace "<http://keechma.toolbox.dataloader.app|keechma.toolbox.dataloader.app>' is not available, ...

I'm facing these two errors.

Is it correct namespace to install Forms and Dataloader?

[<http://keechma.toolbox.dataloader.app|keechma.toolbox.dataloader.app> :as <http://dl.app|dl.app>] got that in namespace definition and it works

i don't use the forms thingie, i usually have personal requirements that never fit with any library

did you add the toolbox to your deps.edn or project.clj ?

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"]

version 0.1.24 is the latest

i got bitten by that too @mihaelkonjevic should maybe update that page you linked

and add a current version to the github project =)

@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

you're hiding a new version from us !

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

well i'm more of a "multi-year projects" guy

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've been solo developing and maintaining not so many project but over many years

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?

yes

@mihaelkonjevic i think i already did read that, and did not agree with you !

interesting, would love to hear more

i think you concluded that validation after pressing ok was the best way

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)

that's almost acceptable !

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

there is a state machine, when you press ok, ok button becomes unusable

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

and everything needs to be revalidated, cannot post while validation is in flight

well, i'm with you on that, but you still need to validate on server anyways

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

i had a solution on my klast project for wizard-like partial validation

but that wasn't very elegant i must concede

because then the server had to know this was a wizard

which is not its concern

or should not be

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

mhh well when you have much data

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

true enough

and I was recently implementing wizards with one step per page and maybe 10 - 20 fields total

which made no sense

well there is an argument to be made for and against them

consider the average user, can't frighten him with a huge form

a wizard gently eases him into filling much data

also a wizard can adapt to previous input

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 😄

yes that's a lot of work

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

I have a question while you're here

what's the reasoning behind only giving access to one controller to your components ?

for eventing

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

allright, but is it good practice ?

oh i see

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)

ahh i didn't look at forms at all, maybe i should

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

yes i stole that pattern from you already =)

you just blindly subscribe all your components to forms ?

yeah

it doesn’t really cost anything

right, if you don't use it

oops

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)

that's not really global

global to the app

true, but still felt a bit dirty

haha

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

yes exactly

is this documented ?

because that's a likely stumbling block, that was to me

yes https://clojurians.slack.com/archives/C0MDSV2LW/p1562353863205000

😄

I’ll add it

=)

anyways thanks for the nice chat, and for that little gold nugget of a vector topic

no problem, looking forward to that lib you’re working on

might be useful for you weird html animation producing devs

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

🙂

i don't know the first thing about django =)

well it’s the same principle like selmer is using (from luminus)

isb't selmer already doing part of what you want?

right

yeah for html

not for reagent components

ohhh i see

so for branding etc, let the customer use templates ?

or pretend they can do it, and do it for them =)

i might have a look to it after all

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

you always can do that though

or maybe i'm misunderstanding

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

might be a good blog topic when you have your implementation

yeah, I have a huge list of topics already, just have to find time to write about them all