Fork me on GitHub
#hoplon
<
2016-09-05
>
flyboarder05:09:28

@laforge49 I found the cheetsheet 🙂 this page has the jquery attributes listed at the bottom https://github.com/hoplon/hoplon/wiki/HTML-attributes-and-JS-events-%28on%21%2C-do%21%29

laforge4910:09:28

@flyboarder Looks like a start. What about things like :click? I suspect there are some patterns (onclick -> :click) which need to be covered, preferably by enumeration.

laforge4911:09:00

OK, it is covered in the same page under on!. My problem is that I don't know js, so I'd love to know all the attributes, including jquery attributes, which take function values. If I had a list, I could then look up things which might be useful for a given problem. As it is, I just stumble onto things and that makes it quite difficult.

laforge4911:09:55

@flyboarder Remember the problem I had with composing elements? I ended up with a solution, putting elements in a cell, which you warned me would lead to a memory leak. What I experienced was that the vector of elements in the cell kept growing and on reload my page was filling up with different versions of the elements.

laforge4911:09:36

Fixed that this morning. I'm doing a for-tpl over a vector of keywords and then using a multi-method to dispatch the appropriate element. Works very nicely and I no longer have dom elements in cells. 🙂

laforge4911:09:07

Here's where I call the multimethod: (div (for-tpl [capability login/capabilities] (login/add-element @capability)))

onetom13:09:21

@laforge49 you shouldn't dereference cells within *-tpl macros because u break reactivity

onetom13:09:02

if login/capabilities is not a cell, then there is no point using for-tpl though. if you want to prepare for login/capabilities becoming a cell later, then you should better code against it as if it would already be a cell and don't break reactivity by dereferencing within a loop

laforge4913:09:24

login/capabilities is a cell.

laforge4913:09:36

I had to dereference capabilities, much to my surprise, because for-tpl did not.

laforge4913:09:10

Are you saying I should dereference capabilities in the multimethod?

laforge4913:09:41

Currently I have this: (defmulti add-element identity)

onetom13:09:08

you should let hoplon dereference it either as attribute values or dom element children

laforge4913:09:20

You are saying I should do this? (defmulti add-element deref)

onetom13:09:05

havent looked at the full code yet, only the part you quoted

laforge4913:09:37

how? Like this perhaps? (div (cell= (login/add-element capability)))

laforge4913:09:14

...testing now

laforge4913:09:51

Yup. That worked. Thanks!

onetom13:09:06

im a bit unclear though what are you trying to achieve with that multimethod

laforge4913:09:32

each defmethod defines a different element.

laforge4913:09:05

The code invoking them does not know which or how many tabs there are.

laforge4913:09:15

Sample capability:

laforge4913:09:06

composition is handled via :require

laforge4913:09:46

The same applies to the server side.

laforge4913:09:49

In the above code, welcome, profile and contacts are the 3 tabs.

onetom13:09:43

sorry, having dinner. will have a closer look afterwards. it's 9:36pm here...

laforge4913:09:08

enjoy your dinner! 🙂

laforge4913:09:48

Since I need the div in the driver code anyway, I can put the toggle there and simplify the components.

onetom13:09:57

you still end up with dom elements in cells though...

laforge4914:09:23

oh yes. so that hoplon could do the dereferencing. If I do the dereferencing myself, it works fine. Guess I must break one rule or another. Which is worse @onetom? @alandipert says having elements in cells leads to memory leaks.

onetom15:09:09

if you use deref and then change login/capabilities during runtime you will get surprising states as a result

laforge4915:09:27

Ah. but it does not change. So I'll switch back to that. But I do like having the toggle in the common code. 🙂

flyboarder15:09:46

@laforge49: I wouldn't rely on a pattern which could cause problems just because your instance isn't having them ;) I fail to see why you need cells at all for your composition? Oh are building a list of elements correct? That can be done without cells, unless I am missing something

laforge4915:09:50

Ah yes. I could use an atom to do the composition. And stick the dereferenced atom into the div as the child.

laforge4915:09:57

Which I did.

laforge4915:09:02

I was getting multiple copies of the children with each reload, but I think if i switched to a map and then pulled out the values that would fix it.

laforge4915:09:02

The problem was that I was appending to a vector each time a namespace was reloaded, which meant that it kept growing. 😄

flyboarder15:09:49

@laforge49: but using an atom is similar to using a cell, you just don't get the reactiveness of formula cells, I would try to avoid both of these for storing elements, regular immutable data structures should be ideal for this

flyboarder15:09:35

I propose something like (-> [] (conj elem1) (conj elem2))

flyboarder15:09:55

And build your list that way?

flyboarder15:09:44

If you have a growing list on reload, it's caused by mutation, that would be a flag for me ;P

laforge4915:09:06

Yeah, I can't use a list or vector. But remember that the whole point is that composition is done without having to modify any code except for being sure that the component is referenced/compiled. So the only way I can see is with an atom or cell, Threading is out as it requires a piece of code that is knowledgeable of all the components.

laforge4915:09:00

So I might as well stick with what I have.

flyboarder15:09:13

@laforge49: I think you already solved it, the index page should know about all the components

flyboarder15:09:03

Once you get it all working I'd be interested to see how it all went

laforge4916:09:30

The demo is working. Next is to replace some ugly logic with specter.

laforge4916:09:44

I'll note that I only need specter on the server side. On the client side I've got Javelin lenses. 🙂