Hey guys, I took a stab at the mk! multimethod, not sure how we feel about it, any thoughts?

The idea is that the mk! multimethod returns a function that is used as an element constructor

@flyboarder don't really wanna keep clogging the github up with my idiocy, but wait so it's not actually correct to pass to an element two consecutive sibling children unless they are in a vector or list? so

(div (p "a") (p "b"))

(div [(p "a") (p "b")])

@jjttjj: it's not so much that it's wrong, more that it's different internal behavior

From your example tho usually you would use the vector form when you are building up a collection of children to display, your PR should solve this tho

@jumblerg there is a form *data* binding problem if combined with if-tpl:

(form
  (text :key ...)
  (if-tpl can-submit-yet?
    (submit "GO" :submit js/console.debug)
    (spinner)))

do you have a recommended idiom to get around this? in hoplon i could just do

(submit :toggle can-submit-yet? ...)
(spinner :toggle (cell= (not can-submit-yet?)))

but there is no equivalent of :toggle in hopon ui, or is there? (i only found (bind-in! img [.-style .-display] :block) in hoplon/ui.cljs)

i got around it with:

(form
  (text :key ...)
  (let [submit-btn (submit "GO" :submit js/console.debug)]
    (if-tpl can-submit-yet?
      submit-btn
      (spinner))))

@onetom: :v is for visibility.

Yeah I just remembered that on the way home

https://github.com/hoplon/ui/blob/master/src/hoplon/ui.cljs#L254

Hmm but the visibility hidden doesn't take the element out of the layout so I can't use it instead of if-tpl, can I?

Hats off to @micha for a great Hoplon walk through at TriCojure - nice presentation

@onetom: in practice, from a ux perspective, i have found it more effective to disable buttons while preserving their position on the page until the required form fields are populated, so i haven't run into this particular issue myself. i don't like to shift the layout around by injecting elements like buttons into the view after some amount of validation has been completed.

certainly there might be cases where this scenario makes sense, however. dynamic binding often comes up short as a mechanism for propagating references from parents to children, even with micha's bound-fn implementation.

And how do you disable a button? You would need an alternate set of styles, right?

something like (elem :sh 300 :sv 60 :c (cell= (if is-complete :blue :grey)) :m :pointer :click #(when is-complete (dothedeed %)))

i've also changed up the form stuff a bit since the version you're using: https://github.com/hoplon/ui/blob/master/src/hoplon/ui.cljs#L632-L640

i've been experimenting with bubbling cells (on events) as a mechanism for setting up an inherited binding (inherited from parents as in css inheritance) scheme as an alterative to using dynamic vars for this. i'm not certain this is a good approach though; i really need to enumerate the various cases where there the dynamic variable model has caused issues to specify what a better abstraction for this might look like.

Yup, I've just started reading the latest formable source before I left the office. We would need to merge with our branch and see if anything breaks

@micha: incidentally, i was thinking about ns+; i wonder if it would make sense to do away with this in favor of a simple ns in a .cljs.hl file.

the ns would have the same semantics, and be more tooling-friendly perhaps because it is consistent. additionally, it would maintain the contract that .cljs files start with ns.

(i had this insight while thinking about deps.cljs...

i don't think it would be more tooling friendly

just like deps.cljs

it would be less tooling friendly

because it wouldn't be the real ns

tools should be able to assume that the ns form is the real one and not something else that is appropriating the name

this is the same issue as we see with .cljs files that aren't cljs namespaces

it interferes with tooling

i, personally, care less about this particular aspect. but this would be an .hl ns, not a .cljs ns.

hl files belong to the hoplon compiler / task.

which would then create a legal cljs file with a real ns for the clojurescript task.

yeah the hoplon task alraedy adds things to the ns decl in a .cljs.hl file

instead of an illegal cljs file with ns+ at the top upstream of the hoplon task.

yeah, but before hoplon, we have an illegal cljs file

that's why i think it should be a .hl file instead. and since it would be a .hl file, then it could use a hoplon ns.

the current ns+ implementation in hoplon tinkers with a file type/contract it does not own.

and typically our file extensions specify which compiler they belong to, eg .java -> javac, .cljs -> clojurescript, in this case .hl -> hoplon. i think it is analogous to invading someone else's namespace.

if we do want to extend .cljs files more generally, with something like ns+ , we should do it in the cljs task i'd imagine (at least within the boot world, these files would still be illegal in the larger cljs ecosystem).

i think the same principle applies to tooling; editors should be able expect an actual ns at the top of any .cljs files. i only meant to convey there might be an incidental benefit of convenience when users associated .hl files with clojurescript in their editors, since the only syntactic delta would be the addition of the :page form to the macro. an ide might not recognize ns+.

yeah it's ns+ because i'm not sure it's a good idea

it's experimental

i think it is a great idea as an nsfor hoplon files. 🙂

it works great now. whether or not you want to propagate it to the clojurescript task, and effectively introduce boot extensions to clojurescript, is another question.

haha i don't think juho would want that

lol. yeah... i heard, somewhere, that :require-macros is no longer needed by cljs; i've not verified this, but that might negate any benefit of doing this anyway if true.

maybe i can turn it into a patch for cljs compiler though if it works well

that's sort of true

50%

it still doesn't support refer our use though

I've actually seen weird symbol resolution situations in cursive

yeah. you should submit a patch for bound-fn too, if they can introduce your binding it in a backwards compatible way.

Sometimes defelem is marked unresolvable

I suspect it happens since we switched to cljs 1.9

remind me what the :refer semantic was?

(:require [foo :refer :all])

ah, yeah. i never use the :all because i don't like dumping a bag-o-symbols into my ns implicitly.

i want to be able to look at my page and know where the things came from.

if it isn't in the ns macro, it had better be clojure.core.

Except it would be very useful for DSLs like Hoplon or cljs.test

convenient. easy at first maybe. less simple. we tried that with hoplon in pages implicit :refer :all. 😕 i find in practice i either refer in a small handful of symbols (even in test), or simply namespace them with :as.

there's a scenario out there, i'm sure, where i might be pragmatic enough to use :refer :all - but i've yet to encounter it.

anyway, my only point is that :refer :all is an edge case so i personally don't care much about it, and i wonder if it does more harm than good. maybe the fact is is missing from cljs is a feature and not a bug because it encourages better practices.

That's the pattern we are following but the inconvenience is that you have to remember what are the frequently used, hence referred, symbols and which ones need namespacing. On top of that you need to maintain a team wide consensus on the ns aliases too...

But you can see the results in our fe repo. It's a workable compromise at the end...

But still a compromise nevertheless...

I see custom ns macros as a harm, because they break cursive, which is the best tooling really these days (for those who have super strong machines with a lot of ram.)

yeah i use :refer when it makes sense

i tolerate it with bootlaces. 🙂

i feel like my code is readable enough, people will figure it out just fine

there is a bit of cargo cultimg with "best practices"

like yeah don't :refer :all everything

but h/div is not sometihng that helps me

nor is :refer [div span p input select .....

that's worse

the idea that some rando off the street should be able to jump into your codebase and start typing immediately is silly

it's a good thing that they can't lol

don't start typing till you know what's going on

and figuring out which namespace refers div is the least of it

yeah, and being explicit helps with that.

i think it can obscure the important stuff with boilerplate

like seeing h/div all over the place is a distraction imo

i could see a scenario where i'd use with with the core hoplon/ui ns, in the same way though.

yeah, that's what i use :refer for.

yeah but needing to type 100 things into :refer is dumb

that's where :refer :all comes in

without the :fing-everything.

i dunno, it seems to work well for me

yeah, but when you refer in 100 things, then you get surprises because you just introduced 100 more keywords that will collide with other things, imho.

so you create a header function, then you get errors. because you :refer :all'd all the html things.

supprise!

i dunno, that's never been a problem for me

that bites me all the time

you see a warning that you're overriding something and which namespace the thing was originally defined in

pretty simple

maybe the warnings were broken for a while, but i wasn't getting them.

why not clojure.core/map and clojure.core/def then?

core has a ton of things refered

because i assume that if it isn't explicitly defined, that it is a core language fn.

but, to be clear, i do think there are scenarios where it makes sense.

they are just rare for me.

who knows, i might start using it in .hl files with ui core at some point. but interestingly, is there an :exclude :all?

interesting, there should be

say i wanted to eliminate all the clojure core fns by default in a view (notwithstanding the necessary ns macro). could be useful, maybe, if i were building views where pretty much everything was a ui elem.

then i could :refer :all hoplon/ui core and :exclude :all clojure.core.

there's https://clojuredocs.org/clojure.core/refer-clojure

(:refer-clojure :only [def defn])

personally, I like ns+, but then I don't use Cursive...

i was wondering if :refer-clojure supported :exclude :all, but i guess the :only construct would work too for the same purpose if that works the way it seems it would.

i really like the semantics of ns+, and i don't use cursive either. i was suggesting that it should be owned by the hoplon compiler and therefore be ns for hoplon .hl files, not .cljs files.

hl files -> hoplon compiler, cljs files -> clojurescript compiler. one compiler/task should not be modifying another compilation task's files.

the files should be legal regardless of the time and their position in the build pipeline.

yeah if we decide that ns+ is legit we can make that the default ns form for .hl files

it is working great for me now

it should be backward compatible anyway

@flyboarder the thing that got me looking at nil child values was this line of hoplon/ui: https://github.com/hoplon/ui/blob/master/src/hoplon/ui.cljs#L609 if you don't give the page a title, none of that form is nil and none of the stuff after it happens.

yeah, .hl can support page or ns.

yeah the fix for the nils is a little more complicated

i guess a page would pretty much always have a title, but it bit me during quick test apps

i think what we want to do is make a (remove nil? args) in the let binding before the cond

and in the places where we do flatten on seq or vector args we need to put a (remove nil? (flatten x)) too

oh yeah, that makes sense

need to think about it though see what the performance implications are

making seqs in clojure is expensive

so you want to avoid doing things like remove in critical sections of code

we may want to say "don't use nil children"

and just not support that

yeah that's fair enough too

that piece of program is in a critical spot

it gets called a lot

@micha i had to duplicate this part twice in the patch i implemented for mk! that might be a sign there is another problem here

it's hard to factor around the parse-args function

i'm not sure we want to make the low level hoplon stuff more abstract

i think that might be something for a higher layer to do

yeah, i observed significant slowdowns in ui when i introduced a seq into the elem constructor.

i'm not even really sold on the INode protocol

yeah, we should sync on that

like the hoplon layer maybe should just deal with dom elements

yep

like really i think hoplon should just be the linkage between javelin cells and dom elements

and that also does imply the *-tpl forms

because of the way cells and dom elements interact

but the attribute providers and so on are really just to help you get started with some reasonably sane defaults

like you should be able to make a simple app with just hoplon if you want

i actually think the attribute providers should be another library/layer entirely.

which means some kind of attribute stuff

well i think it's important that a user can get a basic thing working without other libraries

as long as they're optional

which they are now

yeah, the user would pull that lib though, and get hoplon/core transitively.

I think there needs to be better separation from the custom elements and primitive elements

in core

it doesn't make sense to make that basic stuff separate

basically, you could reduce hoplon/ui to an attribute scheme.

because then we have all the familiar integration issues

not sure what you mean by that

like what we have now is pretty simple and sufficient i think

well like if the attribute providers were a separate dependency

then we'd have the compatibility matrix again

and it would serve no purpose

you don't gain anything by making a separate dependency

you can just use the namespace or not

oh yeah not that they should be a separate library but from core

the same way we do attributes

right i was referring to the attributes there

i think we're doing that the right way now

you could include hoplon/ui or include hoplon/html, or whatever... and hoplon/hoplon comes as a part of those as a dependency.

yeah but what is the gain

then you have hoplon dep conflicts

so you'd need to specify which hoplon you want

it would be the same as boot-hoplon

orthogonality in the libraries

they're not orthogonal

the hoplon.jquery code is tightly coupled to hoplon core

one version of hoplon.jquery isn't guaranteed to work with a different version of hoplon.core

that would just cause confusion

and for zero benefit

i'm less opinionated about this issue though, nor am i convinced my suggestion is the right way to do it.

hoplon.jquery is just one implementation of custom attributes that is sufficient to get started and make some apps

it would be added overhead to make that a separately versioned library

since it is tightly coupled to hoplon core internals

if you want to do a different thing you can just not use it

but hoplon would be useless for making apps without some implementation

so it mkes sense to include at least something

@flyboarder one thing though, i think we should namespace the goog attributes

like :goog/click

or something like that

maybe both?

otherwise its not backwards compatible

could a menu of different attribute options be unnecessary though, maybe in the same sense that INode could introduce options that are undesirable?

why would we want the confusion of supporting jquery attributes and goog attributes?

are half our examples in documentation going to use jquery, the others goog?

what comes next?

@flyboarder compatibility is the reason

i get the idea of supporting one thing, i dunno about a menu of attribute providers.

libraries that are written against the jquery :click for example, won't work if jquery .goog is loaded

@jumblerg we can implement both without causing issues, they are all already namespaced

we should have one standard :click, imho.

that is impossible

all the more reason not to support goog, imho.

the standard click is browser behaviour

the attribute providers extend that however they want

well you can't make aplications on the bare metal of the browser

you always need a compatibility layer

if you want to write your own compatibility layer you'd make your own attribute provider

yeah

but nobody wants to do (.registerEvent ...

you want to do (div :click ...

so that means you're no longer on the bare metal

i guess you could do (div :onclick "foo"

where you have some global function in js named foo

but nobody will ever want to do that

agreed

so i think it's fine to use goog instead of jquery, or even make your own thing

but we should namespace the kws

because they're not going to be compatible

that way we can still have libraries that use other attr providers or whatever

agreed we should allow other people to hook in with goog, or whatever they want to make. i simply don't think we should have goog attribute providers in hoplon/hoplon.

in forks hoplon, in effect.

i don't think it does

if we handle it properly

we'll have some people building apps with jquery, others with goog, and to what benefit?

the benefit is that each has its own strengths and weaknesses

i don't know that we want to encourage that.

yeah maybe we should use the IAttribute stuff

then you could refer in attrs from hoplon.jquery and/or from goog, whatever

(div goog/click #(...) jquery/css {...} ...)

and you could :refer things

yeah

so that would be just (div click #(...) css {...} ...)

hoplon ui can hook in this way as well

yeah i have an idea about the IAttribute thing too

i think that, as we use hoplon over time, we try lots of things, but eventually uncover best practices and idioms; these abstractions tend to get encoded into hoplon incrementally where others can use and benefit from them. we eventually settle on these best practices, and i think we should only offer the abstractions that we use ourselves, that work best for us, as part of core hoplon so we can avoid forking the community (while still giving others the opportunities/hooks to innovate themselves and perhaps find new approaches we can include).

totally

it is better to work through different approaches here as a group, and settle on a single supported approach based on our collective experience and knowledge, rather than giving people a menu of options.

take goog attributes, for example. i haven't tried them. if some of us are using them, and there's a substantial benefit to them, then we should work through that here, and maybe we encourage the use of those moving forward while attaching deprecation notices to jQuery attributes for backwards compatibility.

let's agree on a single approach as a group where we're well equipped to sort through these options rather than devolving the choices to individuals, esp newcomers.

that's a good point, yes

@micha one issue tho is that the compatibility layer is limited to being able to convert regular elements to a compatibility type, this breaks down when elements can only be constructed

for example with jquery I can always convert an element to a jquery element, but there are cases when I cannot do this, I instead must construct the element directly

how do you mean?

you can always use js/jquery function to get a jquery object

like I can go (js/jQuery #some-elem) and that gives me a jquery object, but with many js libraries I must use the libraries constructor for the element

like for an IDE which modifies the DOM

most ide libs need to be constructed

and cannot convert an existing node with each desired method call

but they must return dom elements at some point

that's where hoplon comes in

hoplon doesn't need to be involved in the ide stuff

right when you first construct the element, but currently thats handled by hoplon

but you said the ide library was constructing the elements

right like for a web ide

residing in DOM

right but what is preventing the ide from constructing the things it needs?

like where is hoplon interfering

when elements need to be constructed with their own constructor

what prevents you from using their own constructor though?

nothing specifically but then I cannot construct them the same way as I do regular hl components

I can't mix an external libs constructor and hoplon attributes

the usual way to accomplis that is with defelem

that's how we do jquery plugins for example

but what about when the parent is required to already exist?

I think the main issue is that the jquery pattern dosent always work with other libs

a concrete example would help

https://ace.c9.io/#nav=embedding

like when using ace editor

you can still do that with defelem

(defelem ace-editor [{:keys [text]} kids]
  (let [id (str (gensym))]
    (with-let [d (div :id id :text text)]
      (with-timeout 0
        (doto (.edit js/ace id) (.setTheme "ace/theme/monokai"))))))

something like that

i've done that for some code editor before, maybe it was ace?

you can see a pretty crazy example with the google maps element

it implements the whole api almost in a really nice hoplon attribute style

and the google maps thing itself is totally oop and disgusting to work with

with all kinds of nonsense like things needing to exist with ids and so on