Fork me on GitHub
#hoplon
<
2016-09-28
>
flyboarder00:09:56

@keithsparkjoy totally tracking what you mean now, sorry for the confusion, I think it’s just a jquery issue tho the new method for setting attributes shouldnt have this problem

micha00:09:29

there is also the :svg/viewBox attributes in the current stable hoplon version, right?

micha00:09:40

i believe that was to address the case issue

flyboarder00:09:48

no there is a note in the wiki about it tho

flyboarder00:09:56

it suggests overriding the attribute yourself

keithsparkjoy00:09:11

oh cool - that’s my workaround then

micha00:09:49

i think we can do a bit better though

flyboarder00:09:55

that set attribute method for svg doesnt change anything tho

micha00:09:25

ah it's using jquery

flyboarder00:09:39

that is a better solutions for svg

micha00:09:18

so to fix the :svg/* thing

flyboarder00:09:18

i dont know if we need all those tho

micha00:09:27

we can just have it do .setAttribute()

micha00:09:36

instead of calling the jquery .attr()

flyboarder00:09:49

yeah which should already be included in my jquery split?

flyboarder00:09:57

since i stripped all the jquery

keithsparkjoy00:09:09

@flyboarder do we need svg/*? I dunno if there are any attributes with that prefix...

micha00:09:22

the idea is that those can be case sensitive

micha00:09:44

there are good reasons imo to let jquery handle non case sensitive attributes

flyboarder00:09:44

i think it is probably better to explicitly set it in :svg/* but using the setAttribute method should work for you anyway

keithsparkjoy00:09:04

That pull request sets the SVG namespace on those attributes though - was that an oversight?

keithsparkjoy00:09:10

.setAttributeNS elem svgns (name kw) val)

keithsparkjoy00:09:33

I don’t know of any SVG attributes that have an SVG namespace

flyboarder00:09:33

no that was intended but without jquery in core using the regular attributes :class should work

flyboarder00:09:08

the svg ns is still “there” technically just not explicit

micha00:09:35

your PR with the split had an issue though

keithsparkjoy00:09:38

I’m just thinking that you might not need all those namespace declarations for attributes because that’s a pretty rare thing

micha00:09:47

you can't set the default do! handler in hoplon.core

keithsparkjoy00:09:52

like I can’t think of any case where I would use :svg/whatever

keithsparkjoy00:09:55

on an attribute

micha00:09:57

each attribute provider needs to be able to supply its own

flyboarder00:09:25

that shouldnt be, I should be able to mix attribute providers

flyboarder00:09:40

I have working apps with those PR’s 😛

micha00:09:51

@keithsparkjoy the use case for :svg/viewBox is this

micha00:09:03

if you use jquery to set attributes you get a lot of things for free

micha00:09:12

like working around various browser bugs, etc

micha00:09:25

setAttribute is not an exact science with these browser devs

flyboarder00:09:30

I dont think that is the case anymore

flyboarder00:09:49

jquery doesnt do fancy things with attributes vs properties anymore

micha00:09:58

it special cases some

flyboarder00:09:02

it tells you to be better and use prop

micha00:09:08

i remember getting bitten by that with goog

micha00:09:20

like if you have an attribute named "data-foo"

micha00:09:25

it does weird stuff

flyboarder00:09:27

oh thats another thing we need to fix, aset/aget is going away

flyboarder00:09:41

they need to be exchanged for goog.object

micha00:09:44

yeah i saw the tweet lol

micha00:09:53

it was like a donald trump tweet

keithsparkjoy00:09:35

I’m a little confused still about why you guys want to use :svg/viewBox instead of just :viewBox. Is it just so that you can route to a different multimethod or something?

keithsparkjoy00:09:41

because semantically it’s really confusing

micha00:09:54

it's because jquery will turn :viewBox into viewbox

flyboarder00:09:02

it shouldnt be necessary tho

flyboarder00:09:10

since jquery is no longer setting the attribute

micha00:09:11

but :svg/viewBox doesn't need to go to jquery

keithsparkjoy00:09:20

Then please let’s call it :hack/viewBox instead

keithsparkjoy00:09:31

until it gets fixed the proper way?

micha00:09:37

what is the proper way?

keithsparkjoy00:09:38

you know what I mean?

flyboarder00:09:42

using vanilla js

flyboarder00:09:48

since jquery is not in core anymore

micha00:09:50

that's not the proper way imho

keithsparkjoy00:09:00

I’d really rather just use :viewBox

keithsparkjoy00:09:04

and have it work

micha00:09:07

one thing i definitely do not want to do is get into the browser compatibility layer game

keithsparkjoy00:09:22

because if I say :svg/viewBox it makes me think it has an XML namespace and it doesn't

micha00:09:25

so personally i use jquery for accessing the dom in a sane way

keithsparkjoy00:09:27

and we propagate that myth

flyboarder00:09:46

but then we are keeping the jquery dep

micha00:09:55

i don't want to get a bug report about some platform specific hack i need to do for some specific attribute

micha00:09:17

anyway i simply don't have time to do cross browser framework development

micha00:09:37

i need a layer between my code and the dom

micha00:09:43

one that has all the special cases build it

micha00:09:47

*built in

flyboarder00:09:00

right makes sense, I dont think we need to change anything tho

micha00:09:05

so back to jquery and attributes

micha00:09:16

i use .attr from jquery to set attributes myself

micha00:09:28

this frees me from 99% of the weird bugs i don't want to know about

micha00:09:42

like you can't just set the class attribute, you need to use .style.class or whatever

micha00:09:46

there are things

micha00:09:56

different for different browsers

micha00:09:08

so there is great value to me to have jquery .attr

micha00:09:17

but that means that it's case insensitive

micha00:09:21

or downcased rather

micha00:09:33

svg on the other hand, i know is just normal attributes

micha00:09:39

so setAttribute there is ok

micha00:09:04

so that's the reasoning behind like :case-sensitive/viewBox

keithsparkjoy00:09:12

Right - I like that better

keithsparkjoy00:09:17

it says what it means

keithsparkjoy00:09:29

whereas :svg/foo makes it seem like we’re using a namespaced attr

keithsparkjoy00:09:44

that’s what I meant by :hack/viewBox

keithsparkjoy00:09:54

It’s just a workaround for now

micha00:09:03

ok yes i see now

keithsparkjoy00:09:12

Thing is, all of XML is case sensitive so if jQuery is flattening attribute names they are really screwing up.

flyboarder00:09:16

attr doesnt really do anything special

flyboarder00:09:48

using setAttribute would be more semantically correct, what we are unknowingly supporting is setting properties

flyboarder00:09:57

which we really dont want

flyboarder00:09:17

because you can have both properties and attributes with the same name

micha00:09:29

for me i don't care what the underlying thing is, i just want something that makes sense

micha00:09:35

jquery has sort of paved that over for me

flyboarder00:09:40

right but they are not the same, this breaks polymer for example

micha00:09:44

like imo the browser design is bad

flyboarder00:09:46

and webcomponents

micha00:09:54

interesting

flyboarder00:09:08

because setting an attribute is not the same as setting a property

flyboarder00:09:33

really we should have :attr/* and :prop/*

flyboarder00:09:38

for everything

keithsparkjoy00:09:00

hmm, if you used that how would you support something like xlink:href?

flyboarder00:09:15

that would still need :xlink/href

flyboarder00:09:40

you see the problem right now we are ambiguously mixing them

flyboarder00:09:50

attributes and properties that is

keithsparkjoy00:09:09

hehe honestly I thought that was kind of a cool feature 🙂

keithsparkjoy00:09:13

but I’ve not run into the collision prob

flyboarder00:09:07

webcomponents introduces their own layer to sync the attributes and properties, jquery doesnt do this however

keithsparkjoy00:09:25

So I’m curious - why do you suppose :class wasn’t working inside <svg> frags?

keithsparkjoy00:09:41

It wasn’t being emitted at all without the little hack we introduced.

flyboarder00:09:38

how jquery is setting the attribute

micha00:09:07

why is aset and aget going to be broken btw?

flyboarder00:09:50

something about infered-ness in clojurescript

micha00:09:55

i don't know of anything that's been removed from clojure or broken in all the years i've been using it

micha00:09:18

why wouldn't they make new things for the better aget and aset

micha00:09:30

rather than break basically every clojurescript application in the world?

micha00:09:43

all my applications have those in them

micha00:09:03

and various libraries and whatnot

micha00:09:25

lol yeah that's the trump tweet

micha00:09:41

if i knew using clojurescript would make me totally out of luck

flyboarder00:09:12

yeah i dont understand the change, but I feel like “we have been warned"

micha00:09:36

yeah anyway i know how to monkeypatch the cljs compiler 🙂

flyboarder00:09:11

@keithsparkjoy with master and svg class you should be fine with using regular attributes, the :svg/* is for explicitly creating the attribute with the svg namespace, I think xlink is probably the only other one we need?? and can remove the rest?

flyboarder00:09:49

not that the explicit part is needed just an option

keithsparkjoy00:09:58

Which attribute needs the svg namespace? I don’t know of any.

keithsparkjoy00:09:05

There was the xlink one - that’s the one we needed

flyboarder00:09:48

again I dont think you “need” the ns for svg attributes it’s just there as an option

keithsparkjoy00:09:27

I think it’s worse than that

keithsparkjoy00:09:36

If you were to use it your SVG wouldn’t work

flyboarder00:09:09

it should work, it’s the fix we came up with yesterday

keithsparkjoy00:09:26

The only namespace fix I was after was the xlink one

keithsparkjoy00:09:33

I don’t get the svg one

keithsparkjoy00:09:46

e.g. if you were to use :svg/viewBox it wouldn’t work

flyboarder00:09:19

does it fail for you? that shouldnt happen

keithsparkjoy00:09:29

One sec, let me go see.

flyboarder00:09:35

im going to play with your jsfiddle

keithsparkjoy00:09:31

There’s one that uses viewBox with the SVG namespace - :svg/viewBox.

keithsparkjoy00:09:53

The viewBox attribute isn’t found by the browser because it’s not looking for svg:viewBox - it’s just looking for viewBox.

micha00:09:07

the :svg/viewBox != svg:viewBox

keithsparkjoy00:09:22

it does if you look at the pull request @flyboarder sent

micha00:09:29

ah ok sorry

keithsparkjoy00:09:59

no worries - I’m not sure where you guys are at - so many changes happening

keithsparkjoy00:09:26

I just want to make it clear that if you have a function that sets attributes in the SVG namespace, it’ll effectively be dead code because nobody will be able to use it.

keithsparkjoy00:09:42

That xlink:href one was the rare exception

keithsparkjoy00:09:48

where we really do need a namespace on an attribute

micha00:09:02

yep i think i'm tracking there

micha00:09:22

you only need setAttributeSN for the xlink:foo and things like that

flyboarder00:09:30

then we can probably revert the changes from the Prefix PR and just include the xlink one?

micha00:09:34

otherwise regular setAttribute is fine

keithsparkjoy00:09:37

YES YES YES fly

keithsparkjoy00:09:42

that’s what I’ve been trying to say 🙂

flyboarder00:09:52

hahahah oh gosh

micha00:09:55

ok so here is a question

keithsparkjoy00:09:02

I mean there may be other edge cases like that but I don’t know

flyboarder00:09:05

longest route possible to this point XD

micha00:09:51

with vanilla js, is there a 100% compatible cross browser way of setting attributes and stuff with no special cases?

micha00:09:11

and by setting attributes i mean doing all the stuff i currently do with the jquery .attr() method

micha00:09:17

oh i know i can use it

micha00:09:28

but does the same code do the same thing on all browsers?

keithsparkjoy00:09:48

I suppose you could look at the jQuery sources to see if they have any browser specific stuff for attr()?

micha00:09:02

like if i want to set the value of a textarea and an input and a select dropdown

micha00:09:38

there is the attrHooks thing

flyboarder00:09:48

that is to separate from the properties

flyboarder00:09:59

it assumes attributes are lowercase tho which is false

flyboarder00:09:55

especially when using new stuff like webcomponents attributes and properties can both be any character, including nonvalid attribute characters like $

micha00:09:17

what is the difference between attributes and properties?

micha00:09:26

practically speaking

flyboarder00:09:33

properties are only on the “object”

micha00:09:46

i mean what is the impact when i want to do something

micha00:09:26

like do i need a matrix of when to use one vs the other?

flyboarder00:09:42

listeners are set on the object properties not attributes usually

micha00:09:50

can you just forget about attributes?

micha00:09:55

and use properties all the time?

flyboarder00:09:16

no because attributes are not really part of the “object” as per my understanding

flyboarder00:09:26

they are part of the object in DOM

flyboarder00:09:39

not the JS object itself

flyboarder00:09:09

the most visual difference is with inputs

flyboarder00:09:17

like checkboxes and textfields

flyboarder00:09:17

http://api.jquery.com/prop/ there is a note about attributes vs. properties

flyboarder01:09:23

it would actually seem like using different versions of jquery provides a more inconsistent experience

flyboarder01:09:01

and then there is .data()

micha01:09:08

so it seems that properties is all we want really

micha01:09:13

since we don't have a html file

micha01:09:24

rather the elements are not in html ever

micha01:09:39

they're constructed as js things

flyboarder01:09:03

I dont know that properties will actually set the “attribute” once it’s placed in a document tho

flyboarder01:09:29

like if we set a property will it show up in page source? my instinct says no

micha01:09:33

that's ok i'd imagine

micha01:09:53

you mean in the debugger right?

micha01:09:06

the source won't have it if it's constructed at runtime

flyboarder01:09:27

yeah the debugger but i dont think it sets attributes at all that way

micha01:09:40

wow what a shitshow

flyboarder01:09:49

really most things should be set at attributes and select things as properties

flyboarder01:09:01

properties are the edge case really

micha01:09:20

is there a library that handles this in a sane way?

flyboarder01:09:07

like I was saying there are somethings that provide syncing between attributes and properties by settings listeners during lifecycles but we dont have any of that nonsense

micha01:09:51

i mean something that chooses whether to do the property or setAttribute

micha01:09:22

that has just a single method, setAttrOrPropDependingOnWhichIsTheCorrectOneForThisSpecialCase

micha01:09:30

probably depends on the type of element and the name you're setting

micha01:09:08

so there must be a library somewhere where people have figured out which permutations are setAttribute and which are properties, i hope

flyboarder01:09:32

its a crap shoot really, i think the most sane way to handle it is by using setAttribute and then if you run into issues override the attribute method

flyboarder01:09:28

micha if we move do! and on! that breaks existing things which have extended the attributes doesnt it?

micha01:09:48

the multimethod definitions would be in hoplon.core still

micha01:09:58

just the method dispatches would be moved out

micha01:09:08

so you'd have a blank slate if you want

flyboarder01:09:00

that is the check jquery uses

micha01:09:15

yeah those will throw exceptions i believe

micha01:09:23

if you try to set attributes on them

micha01:09:38

like a text node can't have attributes

micha01:09:43

or a comment

flyboarder01:09:07

right makes sense

micha01:09:42

ok i will push my changes now

flyboarder01:09:55

awesome, im making changes to the prefix PR

micha01:09:05

then we can figure out the prefixes yeah

micha01:09:45

what i want to make sure of is that we aren't breaking anything

flyboarder01:09:02

for sure 😛

flyboarder01:09:17

but i think thats less fun XD

micha01:09:33

this separation is good because now we can try other things without breaking the jq stuff

micha01:09:01

hi @chromalchemy what do you think?

chromalchemy01:09:15

Hi @micha ! I need to (always) catch up. You guys are awesome, always blowing my mind and thinking of everything 🙂

chromalchemy01:09:02

I have a hopefully simple question: How can can a custom element use a value from a from a for-tpl in an attribute function. Like

(for-tpl [x [1 2]] (custom-elem :click #(+ 10 x)))

micha01:09:14

ah i think your issue is that x is going to always be a cell

micha01:09:39

(for-tpl [x [1 2]]
  (custom-elem :click #(+ 10 @x)))

micha01:09:20

the bindings in for-tpl are always cells

chromalchemy02:09:59

Whoops, that example works fine, but what about if the function is defined in the defelem.

(defelem custom-elem [x] (div :click #(+ 1 x))) (for-tpl [x [1 2]] (custom-elem :value x))

chromalchemy02:09:45

the x does not seem to inherit through the custom element

chromalchemy03:09:36

I got it now. Needed to define the variable as attribute in the defelem:

(defelem elem [{:keys [value] } kids]
 (div :click #(prn value) kids))

(defelem mylist []
 (for [x ["Hello" "World"]]
  (elem :value x x)))

chromalchemy03:09:00

Or

(defelem elem [{:keys [value] } kids]
 (div :click #(prn value) kids))

(defelem mylist []
 (for-tpl [x ["Hello" "World"]]
  (elem :value @x x)))

chromalchemy03:09:27

I assume for-tpl is more appropriate when dealing with elements, for the potentially dynamic manipulation...

flyboarder16:09:33

@micha question for you, since elements implement a custom protocol should we move -set-attributes! and -set-styles! to hoplon.jquery? This way if you are using jquery you are setting the styles and attributes with the old jquery methods?

flyboarder16:09:24

I was thinking of providing :attr/* :prop/* and :data/* to explicitly set those with the jquery methods

flyboarder16:09:45

that way if you run into a conflict on the js object you have a way to set the one you wanted

flyboarder16:09:15

basically the provider implements the custom protocol for attributes and styles instead of core implementing it

micha16:09:14

i think the protocol should be doing the current thing, because that's important for compatibility with 3rd party plugins

micha16:09:29

but the attribute provider does not need to use those protocol methods

micha16:09:42

it can bypass them and use its own thing to set attributes or styles or whatever

keithsparkjoy16:09:35

Hey guys, I just discovered that it’s not jQuery that’s lower-casing attribute names on us.

keithsparkjoy16:09:38

It’s the DOM.

keithsparkjoy16:09:51

Get this - there’s a rule in XHTML

keithsparkjoy16:09:57

that says all attributes must be lowercase

keithsparkjoy16:09:04

so the DOM appears to be enforcing this

keithsparkjoy16:09:10

SVG docs are in a different namespace

keithsparkjoy16:09:16

So the DOM doesn’t do that there.

keithsparkjoy17:09:01

“XHTML documents must use lower case for all HTML element and attribute names. This difference is necessary because XML is case-sensitive e.g. <li> and <LI> are different tags. "

keithsparkjoy17:09:18

So my guess is that jQuery isn’t doing any lowercasing at all

keithsparkjoy17:09:24

…and it should just work.

micha17:09:02

where does XHTML come into the picture?

micha17:09:12

jsfiddle is making a html5 doctype

keithsparkjoy17:09:18

I think HTML5 docs follow those same rules

keithsparkjoy17:09:30

Regardless - the DOM is definitely doing something different

keithsparkjoy17:09:52

When you call setAttribute within an HTML5 element, it lowercases the attribute name

micha17:09:59

personally i think case insensitive is a good choice, and svg is being weird, but yeah that is irrelevant 🙂

keithsparkjoy17:09:12

XML is case sensitive

keithsparkjoy17:09:16

For example, if you say <div Class=“foo”> the DOM will lowercase “Class” for you.

keithsparkjoy17:09:24

Because Class and class are different

keithsparkjoy17:09:44

Not sure that’s the best behavior because it’s a band-aid for incorrectly written HTML

keithsparkjoy17:09:51

but that seems to be the behavior

keithsparkjoy17:09:14

So anyway, I don’t think getting rid of jQuery is going to solve that problem. Arguably there shouldn’t even be a problem.

keithsparkjoy17:09:17

with viewBox etc.

keithsparkjoy17:09:35

So the note on the wiki about case sensitive attributes is a bit misleading

micha17:09:59

you are correct

flyboarder17:09:03

but jquery is indeed lowercasing things, I checked the code

flyboarder17:09:37

it assumes attributes are lowercase if it cant find a property

keithsparkjoy17:09:14

Okay so HTML5 is not XML then. Interesting.

keithsparkjoy17:09:18

But SVG definitely is.

keithsparkjoy17:09:42

If you mess up the case on SVG attributes they won’t work properly.

micha17:09:58

html has things like <input type"text">

micha17:09:13

no /> anywhere

keithsparkjoy17:09:53

So jQuery is just overstepping their bounds by always lowercasing.

keithsparkjoy17:09:07

Gosh I wonder if some DOM implementations don’t do that

keithsparkjoy17:09:13

so jQuery is trying to normalize things

micha17:09:20

it's kind of dumb that we're concerned with HTML at all since we're not using it

keithsparkjoy17:09:23

e.g. maybe IE doesn’t lowercase for you

keithsparkjoy17:09:29

so they do it.

keithsparkjoy17:09:39

Although that’s just weird - if case doesn’t matter why would anybody lowercase?

keithsparkjoy17:09:46

for consistency?

flyboarder17:09:48

@keithsparkjoy there is a note about IE9 doing memory leaks

micha17:09:28

we're coming in at a lower level than HTML, it's weird that we need to even know about it

micha17:09:37

like we're directly creating objects in the dom

keithsparkjoy17:09:43

well the HTML spec matters when you’re working with the DOM, no?

micha17:09:53

i wouldn't think so

keithsparkjoy17:09:00

I mean, if they say it’s case insensitive, then Class is the same as class, even with the DOM

micha17:09:05

like java doesn't matter when you're generating jvm bytecode directly

flyboarder17:09:15

XHTML is an implicit spec on the DOM

micha17:09:21

it could be downcased or whatever by the html parser

micha17:09:28

when it instantiates dom objects

micha17:09:35

but that shouldn't need to concern us

flyboarder17:09:53

but i think it is still applied when objects are inserted into the DOM

keithsparkjoy17:09:15

Mind if I update that wiki note with this new information?

keithsparkjoy17:09:20

Just so it doesn’t confuse people?

micha17:09:47

feel free to update the wiki at will 🙂

flyboarder17:09:28

@micha so that PR adds the :prop/* and :data/* options, plus restores attribute behaviour to jquery while leaving core alone

micha17:09:07

looks good!

micha17:09:27

interesting about the extend-type

micha17:09:40

didn't know you can do that

micha17:09:21

replacing protocol methods like that

micha17:09:32

but i don't think we need to do that, maybe

micha17:09:49

it's ok if the protocol does setAttribute or whatever

flyboarder17:09:23

well the version in core uses vanilla js as per the jq split, but the version in jquery will do the prop and node type checking which is what you wanted no?

micha17:09:31

the (defmethod do! :attr in the jquery ns doesn't need to call set-attributes! was what i was suggesting

micha17:09:41

it can call the jquery methods itself

micha17:09:47

bypassing the protocol implementation

flyboarder17:09:48

ah ok i can fix that

micha17:09:07

i think that would prevent interference with 3rd party libs

micha17:09:16

cause the protocol is global

flyboarder17:09:38

mhm, yeah we dont really want to adjust it for the provider since it’s global

micha17:09:44

like when d3 calls elem.setAttribute(...)

micha17:09:51

it will call that protocol method

micha17:09:59

it doesn't want jquery in the way

micha17:09:15

but when i do (foo :title "bar") or something

micha17:09:22

i'd like to use jquery to set the attr

micha17:09:45

that would go through the do! multi

flyboarder17:09:27

@keithsparkjoy can you verify this fails the way you would expect, i added jquery

keithsparkjoy17:09:32

Nope - that looks different. The attribute Bar didn’t even get put on the circle as far as I can see

keithsparkjoy17:09:48

Is that what you are seeing?

flyboarder17:09:56

sorry forgot the “#” character

keithsparkjoy17:09:18

No worries - do a update and send the new link

keithsparkjoy17:09:47

nm I fixed it 🙂

keithsparkjoy17:09:55

Okay yea now it’s doing exactly what I was seeing

keithsparkjoy17:09:59

it’s lowercasing when it shouldn't

flyboarder17:09:05

so it’s jquery lol

keithsparkjoy17:09:22

Right. I did some additional research and it sounds like the jQuery guys just didn’t care to deal with SVG attributes

flyboarder17:09:22

that is essentially what hoplon is doing internally

flyboarder17:09:41

yeah nor did they provide an .svg() method to take care of it

keithsparkjoy17:09:43

There’s all sorts of noise on StackOverflow with guys using jQuery with SVG and having this problem

flyboarder17:09:13

glad we are fixing this up, should make things “just work” in the future

keithsparkjoy17:09:32

yea, appreciate your help with all of this, and your patience

flyboarder17:09:46

np sorry yesterday took so long to get on the same page

flyboarder17:09:02

i totally forgot your version would be using attr instead of setAttribute

chromalchemy19:09:56

What is the point of (dissoc attrs :foo) in this pattern?

(defelem elem [{:keys [foo] :as attrs}]
 (div (dissoc attrs :foo)  foo))

(for-tpl [x ["Hello" "WORLD"]]
  (elem :foo @x))

micha19:09:59

the :foo attribute is just for the elem, not for the div it returns

micha19:09:11

here is a more concrete example:

micha19:09:40

(defelem titled-list
  [{:keys [title] :as attr} kids]
  (div
    (dissoc attr :title)
    (h2 :text title)
    (ul (map li kids))))

micha19:09:49

then i might do something like this:

micha19:09:52

(div (titled-list :class "large" :title "my things"
        "one" "two" "three"))

micha19:09:27

i want the class on the div, but the :title isn't a real attribute

chromalchemy19:09:56

Hmm. I see that it works, but still not seeing the purpose of (dissoc). If I use plain attr it also works. Also, if I (dissoc :class), then I effectively disable the :class declaration when I instantiate the element. But (dissoc :title) enables the :title declaration on the element instance.. This feels like inverse behaviors for different keywords?

micha19:09:27

you're saying the div has a title attribute with my code?

chromalchemy19:09:10

Maybe I'm thinking of dissoc in the negative, where it really means in this context "enable the use of this keyword on this element invokation"

flyboarder19:09:09

title in the example above is coming from parameters

chromalchemy19:09:11

This seems to work, without dissoc , so I guess I'm missing some of the nuance.

(defelem titled-list
  [{:keys [title] :as attr} kids]
  (div attr
   (h2 title)
   (ul (map li kids))))
(titled-list
    :class "large"
    :title "my things"
    "one" "two" "three")

flyboarder19:09:48

the difference is that the title entry in attr is removed with dissoc

flyboarder19:09:44

(def my-map {:a 1 :b 2 :c 3 :title "hi!”})

flyboarder19:09:54

(dissoc my-map :title)

flyboarder19:09:07

=> {:a 1, :b 2, :c 3}

micha19:09:40

dissoc is a clojurescript function, it works like this

micha19:09:03

(dissoc {:a 1 :b 2 :c 3} :a) ;;=> {:b 2 :c 3}

micha19:09:12

it removes a key from the map

micha19:09:44

oh whoops, what @flyboarder said

flyboarder19:09:58

no thats a much better example

micha19:09:59

slack is being weird for me

flyboarder19:09:12

1 liner 😉

chromalchemy19:09:24

I understand what the function does. Buy why remove the keyword from attrs in that spot, when in practice you are using that keyword in the element invocation?

chromalchemy19:09:32

sorry for being dense 😛

flyboarder19:09:01

there is no real value to it in html, you could leave it if you wanted, but usually when your attribute contains an object you want to remove it

flyboarder19:09:46

like a formula cell or some complex data

micha19:09:33

also i don't want to have a title attribute on the div that's created by the titled-list function

micha19:09:39

i don't want this:

micha20:09:37

<div class="large" title="my things">
  <h2>my things</h2>
  <ul>
    <li>one</li>
    <li>two</li>
    <li>three</li>
  </ul>
</div>

micha20:09:45

i want this:

micha20:09:10

<div class="large">
  <h2>my things</h2>
  <ul>
    <li>one</li>
    <li>two</li>
    <li>three</li>
  </ul>
</div>

micha20:09:49

that is what i want when i do (titled-list :class "large" :title "my things" "one" "two" "three")

micha20:09:44

this would also be a problem if instead of div my defelem would do somethign like this:

micha20:09:12

(defelem titled-list
  [{:keys [title] :as attr} kids]
  (foop
    (dissoc attr :title)
    (h2 :text title)
    (ul (map li kids))))

micha20:09:50

that's if foop also has a :title attribute that maybe does somethign completely different

chromalchemy20:09:04

Ok, I got it now. I wasn't inspecting the html output carefully and seeing that difference. I was assuming dissoc had more to do with enabling or disabling keyword usage when using custom elements. Like if in defelem you needed to override subsequent usage of particular keyword .

chromalchemy20:09:58

Thanks @micha @flyboarder! for taking to time to spell it out so carefully 🙂

micha20:09:06

the purpose there is usually to allow the user to include other attributes as well as the ones that your defelem knows about

micha20:09:20

like :class or styles etc

micha20:09:36

otherwise your defelem would need to handle all of those itself

micha20:09:19

that's why it's common to remove the attributes your defelem handles from the attribute map, and apply that to the returned component

chromalchemy20:09:11

And by returned component, you mean the html output?

flyboarder22:09:29

@chromalchemy defelem doesnt return html output but a DOM element