Clojurians Log v2

@dmarjenburgh That talk by Rich Harris is great. Pretty impressive from his talk that svelte framework. The non-leaky component abstraction looks very nice. i.e. css stays where it is supposed to.

similar in its concept of component to my and (mostly) micha's first framework, golf http://golf.github.io/

in the sense that a component is a bundle of js/css/markup, we didn't really take on css in hoplon

I jumped on the tailwind-css/tachyons bandwagon and I'm very happy with the results for styling. Composable css classes ftw.

yes!! I’ve really found with tachyons etc that a lot of the old css / styling pain I used to have just doesn’t exist anymore

looks very interesting, what’s the relationship between tailwind and tachyons?

Two different implementations of the same ideas. I think tachyons is more strict, opnionated and tailwind is more practical (it has more allowed sizes for fonts, spacing in general). We started using tachyons and we migrated everything to tailwind after long talks with the design team.

@flyboarder I’m trying to follow the flow of whats happening when hoplon is creating an element, but there’s a lot of indirection going on. I don’t really follow why it works this way: - You invoke, say: (input :type "text" :disabled true :placeholder "insert text here") - mm dispatch -> elem! :hoplon/default - mm dispatch -> hl! :hoplon/invoke. This parses the attrs in a map - mm dispatch -> hl! :hoplon/attr. This calls -attribute! on each key in the map, the impl calls elem! with the keyword and the value. - mm dispatch -> elem! :hoplon.core/default. The default handler calls do! with the element, key and value - mm dispatch -> do! :hoplon.core/default. This handler calls (set-attributes! elem kvs). This is actually an error, since kvs is not a map of attributes, but a single value. Maybe it should call (do! elem ::attr {key val}) like in hoplon.jquery? What is the right way to extend or provide alternate implementations in this multi dispatch setup? (You can always have custom attributes right)

@dmarjenburgh there is a bit of extra redirection that I will probably remove in the next release, the idea being you can currently completely swap the internal implementation of everything in hoplon, don’t like something change it 🙂

https://github.com/hoplon/hoplon/wiki/Attribute-Providers

This is already possible in 7.2 right? For example I created:

(defmethod h/do! :props/*
  [elem k v]
  (aset elem (name k) v))

@dmarjenburgh namespaced attributes

for example

https://github.com/degree9/uikit-hl/blob/master/src/uikit_hl/height.cljs

With your current :props/* multi-method you cannot create a handler for a specific property, since anything with the :props namespace will always be handled by :props/* what if you want :props/example to be handled completely differently?

this is where the multi-layered multi-methods come in handy, we have a generic way to handle namespaced attributes :<ns>/*, which can each implement their own more specific multi-methods

Yeah, I could always dispatch it down further inside :props/* handler to my own multimethod if I wanted to.

I was more talking about the change from 7.2.0 to 7.3.0-SNAPSHOT, which introduced the hl! multimethod.

ah that was a trial in opening up the internals for replacement

but nobody uses it 😛

it’s something I need to revert before 7.3 lands

Ok. I noticed there was a bug https://github.com/hoplon/hoplon/blob/master/src/hoplon/core.cljs#L432. This should probably call (do! elem ::attr {key val}), but if the changes are reverted I guess that will be fixed as well 🙂

I really want the keyed loop-tpl support and some support for component cleanup, so I was looking at what I can do to get there 🙂

https://github.com/hoplon/hoplon/milestone/4

Anything on that list could be revisited