Fork me on GitHub
#keechma
<
2019-07-05
>
Ahmed Hassan10:07:24

The required namespace "' is not available, ...

Ahmed Hassan10:07:45

The required namespace "' is not available, ...

Ahmed Hassan10:07:59

I'm facing these two errors.

Ahmed Hassan10:07:51

Is it correct namespace to install Forms and Dataloader?

carkh12:07:16

[ :as ] got that in namespace definition and it works

carkh12:07:00

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

carkh12:07:52

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

Ahmed Hassan16:07:25

Yeah, i added it toolbox to shadow-cljs.edn

carkh16:07:20

are you sure your current selected build can see it? looks like a project level problem

Ahmed Hassan18:07:43

I tried in repl, all namespaces are available which are documented here: https://keechma.com/api/keechma-toolbox/

Ahmed Hassan18:07:06

But namespaces which I mentioned are giving same error in repl too.

Ahmed Hassan18:07:46

I'm using [keechma/toolbox "0.1.6"]

carkh18:07:33

version 0.1.24 is the latest

✔️ 4
carkh18:07:52

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

carkh18:07:52

and add a current version to the github project =)

mihaelkonjevic18:07:13

@carkh @ahmed1hsn yeah, will do. I got bitten by an old version in my deps yesterday too 😰

mihaelkonjevic18:07:35

worst part, I had linked dev version in checkouts, so it was working locally

carkh18:07:06

you're hiding a new version from us !

Ahmed Hassan18:07:12

Thanks @carkh and @mihaelkonjevic how can I know latest versions of Keechma and keechma/forms?

mihaelkonjevic18:07:28

you can see it on github

Ahmed Hassan18:07:43

And does keechma/forms have to be added separately?

mihaelkonjevic18:07:57

keechma toolbox depends on keechma/forms

mihaelkonjevic18:07:37

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

mihaelkonjevic18:07:29

@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

carkh18:07:53

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

carkh18:07:34

so, i like to have my forms work just like i want, usually that's server validation, real time reported to the client

carkh18:07:18

i've been solo developing and maintaining not so many project but over many years

mihaelkonjevic18:07:37

I used to hate forms, and wrote at least 10 different libs over the last decade, but it finally stabilized with keechma

carkh18:07:08

i think it's ok to have specific per project implementation, when the time frames are as long as mine

mihaelkonjevic18:07:45

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

Ahmed Hassan18:07:02

Is [keechma "0.3.13"] newest Keechma version?

carkh18:07:29

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

mihaelkonjevic18:07:56

interesting, would love to hear more

carkh18:07:08

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

mihaelkonjevic18:07:10

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)

carkh18:07:33

that's almost acceptable !

carkh18:07:08

what i like is debounced, timout based on change validation, always ask the server as single source of truth

carkh18:07:38

the password confirm case is handled by the server to only report errors when it makes sense

carkh18:07:04

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

mihaelkonjevic18:07:17

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

carkh18:07:26

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

carkh18:07:52

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

mihaelkonjevic18:07:50

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

carkh18:07:59

why then do the job twice, once you have the machinery to do real time server validation there is no overhead

mihaelkonjevic18:07:27

so, I guess it would be possible in Clojure or with custom validation lib, but defaults (like in Rails or Phoenix) are horrible

carkh18:07:30

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

carkh19:07:01

but that wasn't very elegant i must concede

carkh19:07:33

because then the server had to know this was a wizard

carkh19:07:40

which is not its concern

carkh19:07:44

or should not be

mihaelkonjevic19:07:46

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)

mihaelkonjevic19:07:13

I must say that I started to consider them antipattern, but designers sure do love wizards

carkh19:07:32

mhh well when you have much data

mihaelkonjevic19:07:53

and then there is soooo much problems with going back, optional steps and similar

carkh19:07:06

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

mihaelkonjevic19:07:29

yeah that makes sense, but each wizard ends being a small app in the end

carkh19:07:36

true enough

mihaelkonjevic19:07:54

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

mihaelkonjevic19:07:07

which made no sense

carkh19:07:27

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

carkh19:07:51

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

carkh19:07:12

a wizard gently eases him into filling much data

carkh19:07:58

also a wizard can adapt to previous input

mihaelkonjevic19:07:12

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 😄

carkh19:07:04

yes that's a lot of work

carkh19:07:14

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

carkh19:07:02

I have a question while you're here

carkh19:07:25

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

carkh19:07:39

for eventing

mihaelkonjevic19:07:03

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

mihaelkonjevic19:07:42

The reason was that I used to have much more granular controllers before dataloader, so almost each component had it’s controller

carkh19:07:42

allright, but is it good practice ?

mihaelkonjevic19:07:07

nowadays I usually have 1 controller named user-actions for most apps

mihaelkonjevic19:07:25

and most of the state is handled either through the loader or through the forms

mihaelkonjevic19:07:52

but it’s not a rule, it depends on the app

mihaelkonjevic19:07:36

the reason why you would want to do it is to be able to re-map the topic from outside

carkh19:07:48

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.

carkh19:07:26

so i'm asking about eventing, because that's a new controller and i was wondering how i would manage another controller

mihaelkonjevic19:07:18

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

mihaelkonjevic19:07:34

also when you install forms, form subscriptions are added to all components

mihaelkonjevic19:07:47

(they also use namespaced keys)

carkh19:07:00

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

mihaelkonjevic19:07:02

that way there is no orchestration needed before you start using forms

carkh19:07:19

yes i stole that pattern from you already =)

carkh19:07:59

you just blindly subscribe all your components to forms ?

mihaelkonjevic19:07:29

it doesn’t really cost anything

carkh19:07:43

right, if you don't use it

mihaelkonjevic19:07:05

since it just adds the key to the subscription-deps, and if you don’t deref subscriptions they are dormant

mihaelkonjevic19:07:40

yeah, I know I’m against global deps, but convenience won here

mihaelkonjevic19:07:04

(wasn’t an easy decision to make :D)

carkh19:07:16

that's not really global

carkh19:07:29

global to the app

mihaelkonjevic19:07:31

true, but still felt a bit dirty

mihaelkonjevic19:07:05

forms also forced the change that allowed vector topics in commands

mihaelkonjevic19:07:33

because I had a situation where I had a form and wasn’t able to send commands to other controllers

carkh19:07:51

yes exactly

carkh19:07:00

is this documented ?

carkh19:07:16

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

carkh19:07:29

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

mihaelkonjevic19:07:47

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

carkh19:07:21

might be useful for you weird html animation producing devs

mihaelkonjevic19:07:07

I’m also working on some new stuff, but it will take some time before it’s ready for release

mihaelkonjevic19:07:29

biggest thing I’ll release is support for something like django template blocks

carkh19:07:41

ohyes that all takes so much time, already killed 3 weeks on this thing...trying different evaluation strategies and so on

mihaelkonjevic19:07:03

layout components that can have slots where components can put content

carkh19:07:40

probably not for me, i'm a simple man, with corporate customers who don't want any fancy stuff

carkh19:07:16

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

mihaelkonjevic19:07:11

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

carkh19:07:18

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

mihaelkonjevic19:07:33

not for reagent components

carkh19:07:47

ohhh i see

carkh19:07:44

so for branding etc, let the customer use templates ?

carkh19:07:55

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

carkh19:07:05

i might have a look to it after all

mihaelkonjevic19:07:13

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

carkh19:07:39

you always can do that though

carkh19:07:46

or maybe i'm misunderstanding

mihaelkonjevic19:07:35

yeah, but the problem is when you want to change things that require “wrapper” html

mihaelkonjevic19:07:45

then each component needs to know about it

carkh19:07:00

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

mihaelkonjevic19:07:47

oh, I’m using it in a pretty simple way so hopefully I won’t hit it. Although now there are some alternative libs

carkh19:07:19

mhh i'm sure the problem you're trying to solve is real, but i guess i never encountered it

carkh19:07:25

might be a good blog topic when you have your implementation

mihaelkonjevic19:07:00

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