Where can i find examples of components talking to components - in another word , a large app example

@lewix: not sure if this is big enough for what you want but there is https://github.com/staltz/flux-challenge/tree/master/submissions/mynomoto that I did sometime ago.

i played with hoplon...still cannot make a choice between hoplon and re-frame 😕

@mynomoto: thanks

@piotrek: that's what I meant 🙂

we would like to deploy a standalone hoplon frontend to S3 but the source files are also dumped into the target/ dir. what's the idiomatic way to exclude them? (since we are not putting the source maps into production either, there is no use for the source files. or should we just deploy the source proudly? :)

(sift-jar :exclude ...) in the boot task

source files appearing in sources means they're actually set as resources

@lewix: if you want to see the my latest thinking with respect to organization of large applications i have some examples

micha: sure

if you go to http://app.adzerk.com

that login screen's source is here: https://gist.github.com/micha/032367265649dee391b09f6cd456d3ea

the workflow/form-machine on L32 is a state machine that mediates interaction with the database backend

the thing to notice is how we use extremely flexible reusable components there

no boilerplate really

and it does all the complex behavior that a real application will need

like validation (backend only for now), displaying contextual error messages, things like that

also the "i forgot my password" thing works the right way, and doesn't make you retype your email address 🙂

for the overall organization of the application we use composable "contexts"

that is like mutable state (in cells) that is shared among ui components

we use macros to set dynamic vars, and those vars become the refault values for custom element (that's the hoplon way to say "component") attributes

for example form/with-form is a macro that sets up the form context

form context contains dynamic bindings for the form machine etc

custom elements from the form namespace are aware of these dynamic vars and use them if present to configure themselves

the form/with-field macro makes bindings for cells associated with a specific field in the form

then for example the custom element form/validation-message, which is nested in both the form and the form field contexts

that custom element uses context bindings from both of those contexts to configure itself

so you don't need any boilerplate glue

but you also don't need to explicitly pass contexts through all the intermediate elements

so i could wrap that validation-message custom element in any number of other elements that have no need to know or care about the bindings related to the form stuff

also that example is made from all reusable components

it looks like it couldn't be, becaus ethere is basically no configuration in there, so how does it know?

but it is, all forms in the application look like that, pretty much

with some individual things here and there, like the logic you can see in that example around the "i forgot my password" state

that's something that's unique to the login form, that specific workflow

(i'm referring there to lines 50, 56, 61, 71, and 72)

the idea is that you can abstract away the reusable aspects while still exposing all the knobs you need to customize for a specific implementation

and the default configuration is derived from contexts which are set at a higher level than the UI elements

using dynamic extent instead of passing context in a map through the component tree also has the advantage of separation of concerns

the concerns of configuration context and location in the dom are orthogonal

that's why we have dynamic vars, right?

and good factoring and separation of concerns allows you to build more powerful abstractions and eliminate boilerplate and hard to follow logic

especially when you're working in an asynchronous environment like in a browser

the form namespace is here btw: https://gist.github.com/micha/7a734317c1fbf8c93661e38788c44a82

the deeper layers of the application get progressively less elegant, but that's fine because they will all be factored out into separate libraries and require very little maintenance

the part that really needs to be elegant and easy to understand is the application layer, where we assemble the actual appliaction

that's the part we work on to add features and new workflows

using all the general reusable components developed in the lower level libraries and namespaces

we're pretty much at the point with that application now that adding new features hardly ever involves mucking around in lower level code

we just assemble a new screen and workflow from existing components

the validation-field custom element definition, for example: https://gist.github.com/micha/7a734317c1fbf8c93661e38788c44a82#file-form-cljs-hl-L198-L209

or the submit-primary element, which knows when a request is in flight to the backend and shows Working... and disables itself until the request completes

the cool thing is that it manages its own state, and it doesn't need to ahev everything passed to it via arguments

so that element can be created by another piece of code that doesn't know about anything

when you need to pass info directly down as parameters it becomes difficult to make higher-order components

because you need to tell the higher order thing how to pass stuff down to the things it creates

"don't know, don't care" is i think the key to separation of concerns, which is key to developing general-purpose higher-order functions, which is the key to making maintainable applications 🙂

@micha Ln 233 has attr before you merge with attr

@micha how are you binding the dynamic vars? with-bindings? I was looking into this last week and got rather turned around by the different macros for binding dynamic vars

@flyboarder: the macros are just wrappers for the binding cljs macro

totally just an aesthetic move really

probably should have just used binding there, but with my wrapper macros i have the option to include default bindings

you can accomplish a similar default binding situation when you define the dynamic vars too, so not sure if the wrappers really provide much value overall

still working things out there, you know

re: L233 not sure what you mean?

https://gist.github.com/micha/7a734317c1fbf8c93661e38788c44a82#file-form-cljs-hl-L233-L234

ah yeah, that was a sort of recent tweak in hoplon

maps can be anywhere and are interpreted as attributes

@flyboarder: here is the clj file with the form macros: https://gist.github.com/micha/c266cec4c2c36c576445

so it would seem that this method is pretty much the same as passing in the state, with the exception you don't actually have to call the :attribute, does this change how cells are expected to behave?

no change

it's not the same as passing in the state though

just like dynamic extent is not the same as passing values in function parameters

for example intermediate functions don't need to know or care about them

otherwise every function would need to know how to pass things down to any function they call

spaghetti code, basically

(insert my app here)

all global variables, just smuggled in in a map

the advantage of dynamic bindings is that they can refer to anonymous things

and so on

everything in a giant map needs to have a well-known key schema

which means your head quickly explodes trying to understand how things are related to each other

like if every component gets its configuration and whatnot from some giant map

you have effectively recreated a coconut global scope

and soon you start to use namespaced keywords

thereby recreating a coconut namespace system

pointless and an antipattern imho

also maps are immutable, so components can't keep references to things

so when would passing in state be appropriate then? this still feels similar to a custom component with a let and then a child component using some var in the let

yeah it's another tool in the toolbox

the let is for components that are not related abstractions, but are related in the specific instance in which they aer assembled at the application layer

the dynamic bindings are at the abstraction layer

very general

you use let when you're assembling reusable components into an application

where there is nothing reusable there, because it's specific to a particular screen or workflow

ok that makes sense bindings => related abstractions let => related instances

at the application layer you don't form new abstractions, you simply assemble more general things there into an instance of a particular thing

precisely!

the bindings are like the knight in chess

a strategic tool

jumping over other pieces

lol i dunno how far that analogy holds

it's the image i have in my head though

makes sense imo, using it in forms makes more sense now too

as forms are a very general thing that applications do

it's important that the dynamic bindings provide only default configurations

right since they can be different at any time

when you need to override them in a more specific case you can

surgically, and without disturbing the rest of the abstraction

and you can even then build a new abstraction based on the other more general one

we also have a pagination context, for instance

because pagination is a single abstraction that encompasses many different ui elements

and we use that in totally different situations with maximal code reuse

like for example a paginated table of data

with the next/previous page buttons, current page, # items per page, etc

but we also use the same abstraction inside the typeahead widget

because typeahead hints must also be paginated, naturally

totally different application layer, but built on the same underlying abstraction

right and thats where you get to take advantage of the code reuse

yeah it's huge

handling paginated state and managing how to get that data from the backend in a clean no boilerplate way was a huge step toward maintainability

yeah I can already think of instances in my app where that would have saved a bunch of time and pass around way less

the only tricky/messy part is that you need to convert dynamic bindings into lexical ones in the "consumer" if there will be async callbacks thta need those values

unfortunately cljs doesn't have bound-fn

that's how you'd normally do things in clojure when you use dynamic vars like this in an asynchronous program

for example

crap

(defelem submit-primary
  [{:keys [state text active-text] :or {text "Save" active-text "Working..."} :as attr} kids]
  (let [state (or state *form-loading*)
        attr  (dissoc attr :state :text :active-text)]
    [(button/primary
       (merge {:type "submit" :toggle (cell= (= 0 state))} attr)
       (or (seq kids) text))
     (button/primary
       attr
       (merge {:disabled true :toggle (cell= (not= 0 state))} attr)
       (or (seq kids) active-text))]))

lul

the (let [state (or state *form-loading*) part

slack lol

yeah thats what I was thinking of doing

the cells are the async part in that example

which would still allow local state to be used instead

yup

works great for us so far

thats awesome!

great pattern

seems so clean when you think about it

i've been trying to factor it out into something that can be crystallized into a library

but it's surprisingly hard

yeah thats a fine line between a library and the language

indicating to me that it's still not completely right yet

some coconut water still sloshing around in the brain somewhere

i've also been trying to figure out how to make this into a more rigorous state machine thing, but don't know how to do it: https://gist.github.com/micha/622a62d6a52ff419e5ac

want to factor that into a library too, but it would be too specific in its current form

expressing it in terms of a more correct state machine seems like it would help there

yeah but much of that is form specific

although submit and validate are probably pretty common for state systems

interesting challenge

@micha what about when using loop-tpl? for example right now I have this (not the best) https://gist.github.com/flyboarder/8a5055b212785818ebfa53ddeb05e2f2

usually i will make the let binding in the loop-tpl body

not nice

really want bound-fn there

current research is leading toward a type of macro that goes along with the context macros to automate that binding process

or alternatively perhaps a macro for defining dynamic vars such that they can be discovered at runtime, like clojure has

how come this loop-tpl gets executed when my :bindings is set to null?

it doesnt appear but it forced me to do LN21

or is that just the formula cell doing that?

hm really? that looks like a bug

it shouldn't evaluate the body until the seqable is not empty

yeah if I do :class [severity]I get a dose not support name:

also i'm not sure how that loop-tpl is working ,shouldn't it evaluate to just a single element?

yeah compact-message

that error is different

formatting error from copy paste

or did we merge the change that lets you have a vector of classes already?

it should be expecting a map, and it can't get the name of the keys there

yeah the vector works but not when severity = nil

which happens when the cell is reset so it doesnt show anything but it throws an error

i believe it converts vectors to maps, i copied the same part from core and put it in semui-hl

ah so the vector shouldn't work

https://github.com/hoplon/hoplon/blob/master/src/hoplon/core.cljs#L519

it looks for maps or kvs

are you using hoplon ui?

https://github.com/hoplon/hoplon/blob/master/src/hoplon/core.cljs#L518

i think that was included in the reactive-elements branch of hoplon

doesnt that convert it

it does zipmap

which expects key value key value

right so as long as my vector doesnt contain nil it works

otherwise it works like usual :class [:class1 :class2]

that shouldn't work lol

but it does 😛

that should set only class1

thanks to zipmap it gets {:class1 :class1 :class2 :class2}

whoa really?

yeah

so as long as kvs isnt nil

ah ok yes

so that was merged

whew thought i was losing my mind there

hahaha sanity restored

math still works...for now

until we discover force 5

XD

haha

what's force 5?

like known forces in physics, gravity electromagnetism, weak/strong atomic bonds

they believe they might have inadvertently experienced the result a 5th force, other 95% of the universe here we come!

http://futurism.com/physicists-think-they-might-have-just-detected-a-fifth-force-of-nature/

wow cool

@micha I think a simple fix would be to change (seq kvs) to (seq (or kvs [:class false]))

wait that wont work

it needs to be in the clmap

so maybe change clmap if to cond and check for nil

doseq shouldn't do anything if the sequence is empty though

ah i see the problem

its in ->map tho

no i think it's the way you're using cells

oh?

you want :class (cell= [severity])

i think

because severity there is a cell

which is never nil

i mean the cell itself

and vectors aren't cells so hoplon doesn't wire it up reactively

if you wrap the vector in a formula then you get the thing you want

ah ok so it’s becuase im wrapping it in the vector

yeah but i think it still won't really work the way it's supposed to

there doesn't appear to be any way to remove classes there

something would need to diff the classes then

that change worked

which seems overly complicated for such a simple thing

what happens when you add classes to the vector and then remove them?

i would think that the classes won't be removed from the element

because there is no mechanism to remember the ones that were set before

does the same thing on removing them, throws the same error on remove

Uncaught Error: Doesn't support name:

yeah i would probably just use the map

like so? (cell= {severity severity})

that will also make an error

you want to have a map with the classes

or a string

actually not a string

a map

that has like {:ok (= severity :ok) :bad (= severity :bad)} basically

but the severity is my class

how do you mean

severity is a value that is the class name

yeah that's not really supported currently

you need to have a map really

with keys for each severity

and values that say whether that class is on or off

so right now i dont know what the class name is as it comes from the db

i guess ill stick with (cell= (when severity [severity]))

that won't work though

at least not if you want to change the class dynamically

once it sets a class that way i don't think it will ever unset it, no matter how severity changes

it will jsut accumulate more and more classes

well severity should never change it’s the severity of the error that was saved to db

it’s just a key with vectors of errors

ah ok, so you're good to go then

we really can't leave that like that though

not sure how we can fix it other than removing the feature

i recommend you do a db query to get a map of all severity things from the database

well this is my db structure:

they must be enumerable and finite beacuse you need to implement things in css

so they can't be just anything

they can only be a limited set of things that are implemented in css already

so you can totally make a map of them

and if it's not in that map then it's not implemented in css and can be ignored

oh I see what you mean just use the known class names since there are only a handfull

right

because we are going to have to deprecate that class vctor thing

unless i'm missing something, i don't see how it can work properly

hmmm

im sure you understand it more than I so 😛

all it can do is add classes

which is only half the job

right

perhaps i can add a little dynamic binding magic 🙂

so would (cell= (when severity [severity])) cause memory leaks or just static content if severity were to change

??

it wouldn't cause any leaks

ill have to test this

but like once you set severity cell to non-nil it will add a class to the element

and if you set it back to nil the class won't be removed

hmmm so i cant change keys in my db anyway, it would be the same as removing it and adding it under the new name

and if you change the value of severity to a different class, then the element will have both classes

ok yeah i see how to fix it

so (cell= (when severity [severity])) does hide things tho without throwing the error

hide things?

well what is in loop-tpl doesnt show

which is weird that it throws the error, without it

the error is from calling name on nil

when it tries to add the nil class to the element

but it’s calling name on nil once the :bindings have become nil, why is it trying to add the class to the element that it is hiding?

because the severity cell contains the value nil

and you dtold it to add the value of the severity cell as a class to the element

so it's trying to do that

so the attributes are updated even tho the elements are not being displayed

yes that's key

because the cell changes

yes

that's a crucial thing because otherwise you'd need to manually manage how to "catch up" the element's state when it goes back in the dom

that's the kind of thing you need to do with react, they have a ton of protocols you need to implement basically

which is kinda what im doing with the when

with this system it's way simpler though

well you'd need that anyway

beacuse there is still no guarantee that severity isn't nil when it's in the dom or not

unless i change it to a map

the concerns are orthogonal

so is this really a bug then? or simply a poor usage pattern

i think it's a bug, i have an idea to fix it

ok i think im tracking now, so the class is still present while it’s hidden, im just not seeing it because 1) it doesnt change for me 2) either exists or is deleted in my instance

it’s never in another state which could then have both classes

i think if you have a situation where severity is "foo" and then later severity is "bar" you will see both classes on that element

right

just wouldnt happen in my instance but it could if anyone else is using a vector in a loop-tpl like that

right

or with a vector in a cell

gotcha