Fork me on GitHub
#hoplon
<
2017-01-26
>
thedavidmeister02:01:51

@qqq i haven't used the central dbs from other frameworks, but FYI you can stick a datascript db in a javelin cell, dunno if that helps...

mynomoto03:01:17

Adding a datascript db on a javelin cell works fine, https://github.com/mynomoto/github-client uses it. App is deployed at: https://mynomoto.github.io/github-client

dm308:01:50

so the other difference between Hoplon and re-frame is we have to fight for every new user here 🙂

dm308:01:07

it's probably time we distilled Micha's wisdom into some sort of a FAQ?

dm308:01:21

FAQ: * Javelin has cells, but Reagent has ratoms - isn't it the same thing? * Re-frame single-source-of-truth atom is awesome - why doesn't Hoplon have something like it? * Why would I use Javelin if everyone knows React is the fastest/best known anyway? * In my app I have a list with 1e12 elements, will Hoplon handle that? * I hate macros, is cell= a complicated beast that will break all the time? * I can integrate 3rd party Javascript easily into React apps using onComponent* callbacks - how does Hoplon do it? * Boot is weird - can I build Hoplon apps with other tooling? * Does Hoplon have a component toolkit library (like re-com)? * I want to use Hoplon, but it forces me to make too many decisions - can you make some of them for me, please?

thedavidmeister08:01:50

haha, honestly i learned a lot on the final point @dm3 but i get that's not how most people feel

qqq09:01:43

@dm3: I used to use haskell/reflex and almost implemented my own FRP, so complexity / decision making isn't the problem -- what re-frame wins out for me -- is existing libraries, like re-com and re-frisk

dm309:01:36

that's fair

qqq09:01:30

re-com, I think, can be totally stolen -- I believe it's backed by hiccup, not react -- so it should in theory get hoplon to use re-com

qqq09:01:49

re-frisk probably too for that matter

dm309:01:26

I don't think we want to steal re-com

dm309:01:35

we'd be better off building on top of Hoplon/UI

qqq09:01:40

or, write better docs for Hoplon/UI. I look at http://re-demo.s3-website-ap-southeast-2.amazonaws.com/ -- I know what I'm getting. I look at hoplon/UI, no idea what the components look like.

qqq09:01:50

(this is all meant to be constructive) 🙂

dm309:01:51

yeah, it was basically developed by @jumblerg up to this point

dm309:01:58

lets you get rid of CSS completely

jumblerg09:01:10

@qqq: a valid complaint! documentation is definitely lacking; getting the api nailed down with a layout scheme that's rock-solid and covers 100% of the cases has been the priority.

jumblerg09:01:55

i'm happy to share snippets from some projects i've worked on, though, if you're interested and would find it helpful.

qqq09:01:34

I'm not sure if snipplets would be helpful

qqq09:01:41

the complaint was "I can't see what the library provides w/o installing it"

jumblerg09:01:07

i think we have most of the major problems worked out; i just need to find the time to pull them together into a single branch and put together a production release with some solid docs.

thedavidmeister09:01:09

also hoplon ui seems pretty opinionated

thedavidmeister09:01:17

i'm not sure i'm totally ready to abandon css

qqq09:01:45

I'm okay with opinionated -- I'm looking into building my etire UI in either SVG or WebGL (rendering text using multi channel signed distance fields)

qqq09:01:09

but it's not being able to see the elements w/o installing it that seems like suboptimal marketing

jumblerg09:01:37

@qqq: marketing hasn't been an interest of mine up to this point; candidly, i've been creating the interface for use in my own projects - i just happen to be os-ing it along the way.

qqq09:01:38

the comparisons are a bit unfair then; though someone earlier in the day brought up hoplon/ui as hoplon's answer to reframe/re-com, so I've been comparing them since 🙂

qqq09:01:13

not trying to criticize your work; mainly still in the earlier mentality of debating with someone on "why sin't hoplon as popular as re-frame"

jumblerg09:01:19

at some point this may change, but it isn't a priority for me right now. i'm happy to answer questions as i'm able though. i think working code is the best example there is though.

thedavidmeister09:01:46

@qqq in the past, when i've asked about popularity in this chat, it wasn't really seen as a primary goal

jumblerg09:01:47

no worries. 🙂 and criticism is most certainly welcome.

thedavidmeister09:01:14

because if it is, marketing + docs across the board should be a big deal IMO

jumblerg09:01:31

the same question could be more generally asked of clojure. i think it's the best thing out there for building web apps, but most people don't seem to notice. i'm fine with this. 🙂

thedavidmeister09:01:04

well, like everything, it's only a problem if you have a specific outcome you're trying to achieve

thedavidmeister09:01:31

that said, an faq would be nice :3

thedavidmeister09:01:46

we do see the same questions over and over in this chat

jumblerg09:01:29

hoplon/ui is also early stage. i do think it has the potential to be the future once we get to a 1.0 release; i'm convinced this general approach (if not my specific solution) is the right way to go about building user interfaces in the browser.

thedavidmeister09:01:03

and i'm keen to start playing around with it too 🙂 just, not yet convinced that i should put all my eggs in your basket

jumblerg09:01:16

yeah, don't. 🙂

jumblerg09:01:44

i still have the experimental designations and warnings there for a reason.

jumblerg09:01:23

however, we're probably a couple solid weeks of work away from being able to remove them.

jumblerg09:01:37

i'm definitely looking forward to putting a production release out there so i can encourage people to use it instead.

thedavidmeister09:01:04

well, i've heard nothing but good things

thedavidmeister09:01:26

i've been maintaining a growing library of my own hoplon-based components for my own stuff

thedavidmeister09:01:45

it will be interesting to see how they might work together, or if i should port my work, etc.

jumblerg09:01:31

yeah, i suspect they will. i think once we get the ui project out the door, then we can start building stylistically opinionated toolkits on top. the components you're accumulating might be really helpful for this.

thedavidmeister09:01:12

the components i've been making really rely on the concept of cells

thedavidmeister09:01:52

like i made one that uses a ResizeObserver polyfill, and you pass it width/height cells that it keeps in sync with its dimensions

thedavidmeister09:01:58

so you can hook that up to children, etc.

thedavidmeister09:01:31

like, a lot of them don't have much to do with styles, but managing cells and data

jumblerg09:01:55

incidentally, the goal with ui is actually be unopinionated. it is simply exposing the existing object model that's stuck behind a rather crummy api that was created for documents with an alternative api that offers a few general primitives appropriate for applications.

jumblerg09:01:25

an aom instead of the dom, if you will.

thedavidmeister09:01:26

well that's good then

thedavidmeister09:01:36

sounds ambitious

jumblerg09:01:27

it has no visual designs whatsoever; the components are invisible by default until you stylize them.

thedavidmeister09:01:46

ah cool, so that sounds more like what i've been doing

thedavidmeister09:01:52

like layouts and things?

jumblerg09:01:44

it also lacks things like drop down menus because these incorporate stylistic and ux concerns; rather, it has a pick list that could be stylized as a list of radio buttons, a drop down, or something else.

jumblerg09:01:22

it gives you the tools to do your own layout.

jumblerg09:01:30

it takes all the different positioning and layout schemes defined in css that come together in ways that are often hard to predict and replaces them with a single elem that does it all in a more consistent way.

thedavidmeister09:01:58

ok, yeah, so it's a more like a replacement/augmentation of the box model?

jumblerg09:01:07

it defines it's own box model, using combinations of html elements internally to implement it.

thedavidmeister09:01:37

yes, well in that case you really will need good docs 😛

jumblerg09:01:11

basically, you tell the ui box model that you want a vertically centered elem, and underneath, it does the stuff a designer might do to vertically center an element.

jumblerg09:01:06

the readme does explain the major parts

thedavidmeister09:01:55

well, i gotta grab some dinner

jumblerg09:01:35

all layout can be done with just a few attributes, the :size (which is set on the element directly), and the position attributes :padding, :gutter`, and :align (which are set on the parent to position the children).

jumblerg09:01:18

that's pretty much all you need for the vast majority of cases. should be simple to document.

thedavidmeister12:01:04

hey, is there a way to deal with this situation?

thedavidmeister12:01:08

(defelem foo
  [attributes children]
  (div
    (if-tpl pred?
      (div attributes children)
      (span attributes children))))

thedavidmeister12:01:23

the problem being, children is "consumed" by div

thedavidmeister12:01:57

is there a way to clone or somehow share that so the elements can appear in span as well?

mynomoto12:01:27

(map #(%) children) could help if the children are elements

thedavidmeister12:01:35

i just tried this

thedavidmeister12:01:39

(let [logged-in? (or logged-in? auth.state/logged-in?)
       clone-children (fn [] (map identity children))]
  (h/div
   (h/if-tpl (j/cell= logged-in?)
    (logged-in attributes (clone-children))
    (logged-out attributes (clone-children))))))

thedavidmeister12:01:52

didn't seem to help?

dm312:01:24

you need to actually clone DOM elements

thedavidmeister12:01:51

that's what i was thinking

dm312:01:03

only copies intrinsic listeners

dm312:01:09

pretty sure this won't copy the :click stuff, etc

dm312:01:56

yeah, maybe you can do something with your specific case?

dm312:01:51

it's a pretty interesting case if you ask me

dm312:01:21

maybe you should be if-tpling some other part of the UI if the children stay the same?

dm312:01:12

I can see how this will break if you try to copy input fields

dm312:01:46

will also break if you have an explicit :id set

dm312:01:04

I think this should really detach the elements in one place and reattach in the other

dm312:01:18

cloning will only work in special cases

thedavidmeister12:01:04

that sounds right

mynomoto15:01:26

Calling the elements as functions didn't work?

mynomoto15:01:02

identity will return the same element.

dm316:01:50

AFAIK calling the same element will only reset the attributes/children to whatever you provide

dm316:01:17

so (def x (div (span "hi"))), (x) will result in an empty div

dm316:01:52

it will add attributes/children

dm316:01:05

so effectively it should do nothing

mynomoto16:01:11

@dm3 yeah, I tried it now, it works only on the first time and them it breaks 😕

chromalchemy21:01:49

@thedavidmeister I started using UI a while back, the ran into an obstacle and had to move back to CSS for a while. Hoplon does give you nice tools that make abstracting over CSS a fun challange. I was using Basscss for basic classes, Garden to generate my own classes, and :css (cell= {...} For direct and dynamic styling. But it was a bit confusing to jump back and forth between all this. Now with newer versions of UI, you can pass classic Hoplon elements (like (Div ...) into a UI Elem, And those can be styled like always with the above methods. So I am locked into usin UI at least as a global window container, but after that I have an escape hatch into traditional CSS, frameworks. Or maybe only a specific custom element has CSS encapuslated in it for things UI doesn't support yet, like transparency and z-axis, local to that element container.