@onetom: just because of simplicity, also I don't really want to duplicate logic on a dozen different a elements if i can help it. It's fine for one link, but not if i have to get the logic working across what could become headers/footers/pagination/etc.

@onetom: i'd consider sticking cells inside the do! but probably never straight on the element

(defelem a+ [{:keys [href] :as attrs} kids]
  ((a attrs kids) :class (cell= {:active (= href route)}))

((a :href x :class "some non-dynamic classes") :class (cell= {:active (= x route)})) looks really interesting

i want to give that a whirl when i have the chance

then u can also extend what gets included into .hl namespaces automatically, so u wouldnt need to manually include this a+ into every other namespace

@onetom: yeah, we had a chat about a special element

i just tried this recently but cant remember where can i find the example code

i actually got really deep on this active class stuff when working on the Drupal 8 upgrade a while back

there's a bunch of reasons I prefer an attribute over a new element type

sure, but it's an already existing built-in feature of hoplon to do the addClass stuff, so i really see no benefit of doing it yourself

no, there's not

the syntax you showed me is something i didn't know about before

dont think about it as a new "element type" it's just a function which takes away boilerplate...

but i think there is a benefit to a new attribute that can add itself if needed to the DOM

u can also call it just a too if u don't mind getting a warning about the re-definition of it

it could be a data attribute

doesn't have to be a class

so existing code doesnt have to be changed

yeah but it does

if i come up with a new reason

so i make a++

and does that wrap a+?

or... do i need a+&++ someday?

etc..

what if i'm making pagination and I want "active" "next" "previous" "recommended"

or something

i made elements for that myself since the resulting code reads better using such domain specific terminology...

i wouldnt expect to see pure anchors in my code with lots of boilerplate options, but i would prefer a (next :href "x") instead

oh well, i think i'm going to make a hybrid of what you and alandipert suggested

@onetom: i think the preference would be dictated more by the nature of the app/codebase than something you could generically say is "best"

also since you can provide a hash-map as a parameter to a dom element, i can imagine that u can compose you correlated attributes with a function, like: (a (active-on "/path") :data "x" :target "_blank" (img ...))

that's originally what i had

basically

(defn active-on [path] (hash-map :href path :class (cell= {:active (= path route)})))

that's preeety close to what i was doing

and what i'm looking to simplify a bit

just to make it look more pure htmly?

mmm yeah

but really, going from (active-on "/path") to :active-attribute

is all i'm thinking

and shifting the active-on to part of do!

it seems much of a muchness to me

except the attributes would be a bit more of a formalisation of what i'm trying to do IMO

I could put some docs together for a list of custom attributes pretty easily

i think it would be harder to explain to someone else all the functions that need to be used

i dunno though?

i still want to play around with a few different options

but it would be easier to explain to use a custom element but with standard attributes, which encapsulates such interplay between attributes (or even potentially other kids) imho

hah, have you ever used Drupal's render API?

using do! feels too generic to me. the meaning of an :active attribute might vary from dom element to dom element, yet you would need to define all these different behaviors in the same multimethod definition...

well basically, Drupal has the ability to setup custom elements

no, i was avoiding such "turn key" systems for many years now. generally pretty much anything php or even python based and i fell out of love with ruby too

attach JS and the rest

very similar to a custom element here

just inferior

im sure

pretty similar tbh

based on what i've seen

but with different ways of doing things

actually, some things are better

like, i can "hook into" the rendering of other elements defined elsewhere

and some things are worse, like it's more fiddly/verbose

that's the "old stlye" jquery approach where u separate the element construction from its behaviour definition and as a result u have to assign "addresses" to the elements which u can use like C pointers later to bind behaviour to them

hey?

in html they are "CSS pointers"

you can attach JS and CSS to elements

you can totally put behaviour in the element definition

that bit is beside the point

what i'm pointing out is that there's been a community effort to provide different element types

which is awesome

they all have attributes which are "standard" to the element itself

but when you try to look for patterns across different elements

like does #title always mean the same thing?

the answer is "it depends whether the author of the element implemented it correctly"

so, my opinion is that you find yourself with a bunch of attributes you do want to be able to formalise across all elements

and also the ability to have elements that define their own behaviour and compose other elements

that's a big part of the reason why i like hoplon

Drupal has some ability to standardise attribute behaviour, but it's much weaker than the element definition framework

so you generally end up with slight inconsistencies

that tend to snowball over time

do u have multiple (page "...") definitions in your project?

yeah

is that bad?

so u r planning to use hoplon with prerendering to provide "templates" for drupal?

no

i'm not using drupal at all

ah, ok..

do u know our homepage project? https://github.com/exicon/homepage

i'm saying the drupal render API is a close enough of an analogy to the specific thing we're talking about

to help me articulate a point 😛

u might see a lot of actual use-cases in that

yeah, that looks pretty useful as an example

thanks

yay

; Workaround until/unless  gets done.
(defn- get-href
  [elem]
  (.attr (.$ js/window elem) "href"))

(defn- set-attr!
  [elem k v]
  (.attr (js/jQuery elem) k v))

(defmethod c/do! :data-current-path
  [elem _ _]
  (if (url/current-path? (get-href elem))
    (set-attr! elem "data-current-path" "")))

; All our nav links.
(def links [
  (c/a "WIP" :href "/")
  (c/a "Style Guide" :href "/style-guide.html")
])

(c/defelem support []
  (c/nav (map #(% :data-current-path) links)))

my css can point straight at a[data-current-path]

@onetom: @alandipert @bsima thanks all, i learned a cool trick today between the three of you

@thedavidmeister: cool! btw you can put thi sin your own code to use get on Elements:

(extend-type js/Element
  cljs.core/ILookup
  (-lookup
    ([this k] (-lookup this k nil))
    ([this k not-found]
     (if-let (.attr (js/jQuery this) (name k))
       v
       not-found))))

i got it down to

(defmethod c/do! :data-current-path
  [elem _ _]
  (if (url/current-path? ($/attr elem "href"))
    (elem :attr {"data-current-path" ""})))

; All the links for our nav menu.
(def links [
  (c/a "WIP" :href "/")
  (c/a "Style Guide" :href "/style-guide.html")
])

(c/defelem primary []
  (c/nav (map #(% :data-current-path) links)))

@alandipert: is what you posted a way to make this work?

; If the href of an element is the current path add data-current-path
(defmethod c/do! :data-current-path
  [elem _ _]
  (if (url/current-path? (:href elem))
    (elem :attr {"data-current-path" ""})))

@thedavidmeister: i don't think so, it's a substitute for get-href

yeah that’s all i changed i think

oh sorry, slightly different syntax in the two things i posted

so instead of

(.attr (.$ js/window elem) "href”)

can i do

(:href elem)

?

with your latest code?

hm, not quite: (get elem :href)

altho (:href elem) may work, not sure

i would guess that works because under the hood the keyword data type implments IFn as get

also my guess

what i dont quite get is "...it's literally impossible to store zero information in the DOM..." i might have been your experience, but in the past few years i didn't have to store anything in the DOM since i started using angularjs, then hoplon

(extend-type js/Element
  cljs.core/ILookup
  (-lookup
    ([this k] (-lookup this k nil))
    ([this k not-found]
     (if-let [v (.attr (js/jQuery this) (name k))]
       v
       not-found))))

@onetom: the href is “information” in my books

@onetom: so is whether something is a div or a span or anything else, it’s all information

@onetom: so is every attribute

okay, so the misunderstanding is what "store" means

to me store means the authorative/primary location of information within some address space

@alandipert: you had a couple of minor syntax issues, but i figured it out

the dom element attributes hold copies of such data, but thats we don't really refer to it as "store"

because we dont go there to get that data

we just put copies of other data there

@onetom: mmm, i’m not

@onetom: i’m creating links, then later in my execution, i’m checking some value on the links to make a decision about something

then u will misunderstand many other people too probably

@onetom: the a is the store of the href

you can avoid the redefinition warnings by using (:refer-hoplon :exclude [a])

then you need to refer to the original a as hoplon.core/a of course

i see what u r doing, sure. it's a very imperative style thinking. with that approach u will find yourself trying to read element attributes.

you’re assuming what I’m thinking. i just don’t really understand why (my-link :foo) is OK but (:foo my-link) is not

the original http://hoplon.io site had a diagram of a uni-directional data flow

have you seen that?

no

i haven’t seen the original http://hoplon.io site

the idea is that having data flowing in a restricted direction can greatly simplify the amount of code u need to write

and how is this not uni-directional?

going from attribute A to attribute B

that's why u only want to set dom element attributes, but not get them

but i’m getting A to make a decision about B

roughly speaking

not getting B to make a decision about B

and did the value u are getting from A got there?

I wrote it, in a different part of my program

i made a link element “somewhere else"

with attribute A

now i’d like to generate attribute B

so B should also get it from that other part of your program

why?

that’s nothing to do with “unidirectional flow"

in this case, it makes my program less DRY to do so

and opens an avenue for future inconsistencies and potential bugs

quite the opposite

most of the time you want the attribute to be reactive, no?

which would make the ILookup implementation inadequate

the reason for getting the value of A "from its original place" is that you have the chance to keep the value there on its own, without being attached to more complex data, like a DOM element, which can be mutated in many ways even by user interaction

@onetom: but “the original place” is the a that i created

@onetom: i could make a list for the data that I make an a from

but that really seemed like overkill for what i’m doing

maybe you should implement that approach too to make a proper assessment

i started with that approach

u will should find that it's a lot simpler and actually quite straight forward approach

comparing [(a …) (a …)] then adding a single attribute (the same attribute, based on a condition, to every a

have u used any cells?

to building a hash map up, then processing that to build a

@onetom: i’ve been asked that a bunch of times, and every example i’ve seen makes things more complicated because it adds an extra layer of abstraction that isn’t needed here

cells look great

but i also think they’re overkill here

and implementing various protocols is not an extra layer of abstraction?

how about metadata on the element

(with-meta (a ....) {:some-data 100})

since the information you're storing on the element is clearly "meta"

@onetom: i have quite a bit of experience with this particular problem in other frameworks that suggests it’s useful to be able to handle href in a standard way for links, not tied to the definition of how you process the link for rendering/behaviour

let’s try a different tack

i have a pretty good idea of what problems

; If the href of an element is the current path add data-current-path
(defmethod c/do! :data-current-path
  [elem _ _]
  (if (url/current-path? (:href elem))
    (elem :attr {"data-current-path" ""})))

; All the links for our nav menu.
(def links [
  (c/a "WIP" :href "/")
  (c/a "Style Guide" :href "/style-guide.html")
])

(c/defelem primary []
  (c/nav (map #(% :data-current-path) links)))

solves, compared to trying to make a custom element

and then needing to deal with all the different things that are just like this and might want to be used to together

what concrete problems am I causing for myself?

there’s only unidirectional data flow, because it goes from attribute A to B

strictly

and “because cells” isn’t convincing, because plenty of things work just fine without cells

despite cells being a useful tool to solve problems

wait what happens when the current path changes?

a different link will have the attribute

that will update itself?

if you’re on “/“ then the first link has it, if you’re on “/style-guide.html” the second link has it

well it’s a new page

i’m not using routes

oh

i see

micha: he is not talking about SPA

i’m going old skool

soz

lol

HTMLing like it’s 1990

it's 1990 somewhere

so if i was using routes then i’d use that routing cell, looks cool

or that's what jimmy buffet would say

but i’m not, so KISS won out

so what do you want the html to end up like for these links?

<a href="/foo/bar/" ...>...</a>

also HTML or DOM?

<a href="/" data-current-path="">WIP</a>

with a data-current-path attr when the link is to the same page that you're already on?

like that

as i suspect you would actually like to see different static HTML for every page

<a href="/style-guide.html">Style Guide</a> or that, if not the current path

what does the "current path" denote?

i just um… a[data-current-path] in my CSS

because yolo

too cool for classes

i see

ok

so you want at the end of the day to mark links to get handles to them in css land

yeah

based on a rule on the href value?

i mean really, a class is fine too

yeah

but alsoooo

later

if i make a footer menu

or “something"

use the same thing to get those links behaving in the same way

and also

i might want to do something else to any of these links based on the href

like add a click-me mark, for CSS styling

hypothetically

and it would only be OK if i could have click-me logic running on the same elements as active logic

well if you're thinking in terms of organizing for extension it pays to not yolo the foundation

and i don’t know ahead of time which things will need click-me, which will need active and which will need both or neither

@micha: i’m just yolo-ing the difference between CSS styling based on a class or attribute

@micha: i wouldn’t be here having this convo if i was yolo-ing the whole thing 😛

like if you want the easiest thing with no overkill you will be at odds with making a thing that will be extended cleanly for years as it grows huge

ok yeah

so this href situation looks a lot like a use case for protocols

based on what I just said though

i feel like “custom attribute” seems like a better idea than “custom element"

your element could implement IHref protocol or something

as long as i respect the one-way data thing

and have a method that uses .attr to get/set the value

you can use specify! to dynamically add protocol implementation to instances at runtime

so the IHref could be implemented differently for different elements

which is what you're going to need at the end of the day

ok, i haven’t used specify! yet

i’ll have to look that up

i think that implementing the ILookup protocol to fetch the attr would be something we'd want to work for everyone

but it sounds like I’m still getting and setting attributes

which would mean it would need to return a cell

so I’m right back to the start

which is

I don’t see the harm in (:foo elem) when we have (elem :foo)

we don't have (elem :foo)

although, yes, i see the harm if it’s the same :foo and the same elem

we have (elem :foo value)

😛

@micha: you are right, because i tried that earlier and it totally did not work, lol

(elem :foo value) is what we have

i tihnk one problem with assuming symmetry between (:foo el) and (el :foo) is that there may be no sensible inverse sometimes

i think a lot of times, even

oh, what’s an example of that?

well :foo might mean different things to different elements

for some elements it might be for side effects only

things like that

ah sure

i get it

this is where the protocols come in

because you find the name that corresponds to the intent

not just a name

you can achieve the same with custom attrs thoguh, by namespacing them

like (el :foo.bar/baz ...)

cool, so

let’s see if i have this straight

if i go ahead and extend do! then i get a custom attribute

BUT despite that attribute being intended for a you could stick it on whatever

totally

and end up with something that is harmless in this case, but more generally, not so harmless

BUT if i try to make a custom element

also the current hoplon implementation is incomplete

i mean defelem now is really just defn with some syntactic sugar

i run into issues trying to juggle all these different attribute handling things that could get pretty complex later

which means that when you do (a :href ...)

the :href is passed as an argument

to the constructor fn

so consider the case:

AND because custom elements exist, we can’t do (:foo elem) because :foo is not always an attribute, it could just be a parameter the element does literally whatever with

(defelem foo [{:keys [yolo]} kids] (a :href yolo kids))

BUT because we know that a provided by core always uses :href as an attribute, we can extend the way a works using this specify! thing, to respond to the :href

((foo) :yolo "heythere")

so we're going to fix this in the next release

yes, pretty much what you said

you can make a namespace like app.attr perhaps

and have a IHref protocol in there

with method (href [this] ...) and (href [this new-value] ...)

perhaps

now you can use specify! to implement it on instances

or extend-type to implement it on prototypes

and you can do (app.attr/href (a :href "" ...))

this is the issue with coming from another framework

lol

i feel like this is the very first thing i asked

but i obviously had the wrong terminology

i'm not saying that's the only way, just a way

no, it’s what i wanted to do from the start, haha

i know how to do all these things in Drupal, but they all have different names, that just makes me say the wrong thing to you guys >.<

we need to do more experimentation with different ways to organize things

this is what i meant by “hook into"

because hoplon is very different from the other things i've used

you can end up with very different implementations

we don't know the best way yet

yeah, i don’t know about the wider hoplon stuff, but what we just talked about now is pretty familiar to me

but different names and syntax and everything 😞

yeah it's standard OOP approach, minus implementation inheritance

the ILookup approach might still work though

if we can work out a sensible way to get the inverse function

is there any plan to make elements work more like collections

it is definitely simpler than the OOP approach

yeah we had all of that in the very beginning

and make the bits you send through for side effects knowable somehow?

well the problem is when you build a reactive application

which is what i do

it just doesn't really help then

like clojure already has excellent collections

it's always been better to separate the data from the presentation

that’s not really why i was thinking it would be useful

i was thinking it would be useful to use clojure functions that work on collections to help with the presentation

interesting

how would that look?

well… that’s pretty much what i’m trying to do, lol

if you forget that i’m using a data attribute

that one line of CSS targets

and replace everything i said earlier with “and add CSS based on the href"

or something else

well you can definitely do that, you mean like inline css?

then say you want to map over some links, or reduce the attributes of an element to a CSS rule

yeah I can

but I basically am

like

right yes

the difference between a dedicated CSS rule in a file using an attribute, and an inline CSS rule

...

totes splitting hairs

ok i must ride

i'll be back in a bit

np

it’s getting late here

@thedavidmeister: thanks for really digging into this and taking notes along the way

:thumbsup: 🌈

hah, np, i’m getting heaps of value from this chat

least i can do is take notes

@thedavidmeister: very interesting conversation indeed

u summarized very well what i was trying to tell u. regarding syntax sugar encouraging bad practices, i would point to the example of "web steps" bundled by default with "cucumber". people got the idea from that that they should write acceptance test using those web steps, like:

Given I visit the login page
And I fill out the user field with x
And I fill out the password field with s3crEt
When I click login
Then I should be on the dashboard page
And I should see "my name" on the menu bar

a few years later the authors said it was a big mistake to provide such helper step definitions because it polluted the whole spec by example movement and a huge masses of people misunderstood it and they indeed just wasted a lot of their time trying to maintain such brittle tests until they abandoned them and just badmouthed the whole idea.

in hoplon 5 for example you had to say :on-click and :do-class. it took several hours over the course of ~2months for us to change our code base when we were transitioning to holpon 6 and it took further weeks before everyone forgot the hoplon5 "notation". there was quite a few confusing weeks where some of our stuff was on boot1+hoplpon5 and others were already converted to boot2+hoplon6

normally we'd leave those things in for compatibility, but one of the goals of hoplon 6 was to improve performance

and one way to achieve that was to remove some of those code paths