Fork me on GitHub
Rohan Nicholls14:10:45

@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

Rohan Nicholls08:10:39

Had a look through the docs. Seems you and Micha spend your time ahead of the curve. 🙂 Just out of interest why did you decide not to tackle the css side of components? I have to say I have been finding it very useful to have css isolation within components.


for hoplon an initial goal was designer-friendliness, and we decided to try to impose as little as possible on their toolset/workflow


in practice though we ended up slicing up CSS the designer gave us into defelems


and took ownership of the CSS


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

👍 4

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.

👍 4
Rohan Nicholls08:10:10

Isn’t this just bootstrap? Basically, all variations have classes created for them, and you just include classes as you need them for everything? e.g. padding, flex etc.

Rohan Nicholls08:10:30

I’m not knocking it, just wondering how it is much different?

Rohan Nicholls08:10:53

(this impression was based on the home page of tailwind)

Rohan Nicholls08:10:49

Okay, two obvious problems they seem to have a solution for: - extracting patterns into a separate class - overrides for a user’s themes

Rohan Nicholls08:10:56

Will check it out.


It's very different in practice. You can create your own custom components composing tailwind/tachyons classes. They will not look "bootstraped". But you will not have something that is almost the same with 1px difference because there is no class for that, which makes things more manageable.

Rohan Nicholls06:10:31

Okay, that sounds really nice. i started looking more deeply into it, and it is very nice. Do you use it with hoplon?


I haven't really used hoplon in a while because of native apps. But it will work with hoplon, no problem with that.


@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 🙂


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

(defmethod h/do! :props/*
  [elem k v]
  (aset elem (name k) v))
because I often want to set properties instead of attributes. What would be a use case for the multi-level multimethods?


@dmarjenburgh namespaced attributes


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 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 🙂


Anything on that list could be revisited