FAQ

Welcome to the hoplon/ui FAQ! More Q&As to come. If you don't find what you are looking for, come by the Hoplon Slack Channel and we will be glad to help!

How can I use it?

As time of writing, hoplon/ui isn't available yet in clojar. But, of course, and can use it and, in fact, it would be great if you gave it a try! While we continue to uncover occasional cases we didn’t account for, this is the fastest we’ve ever built a client side application.

In the hoplon/hoplon repo, there is a branch that introduces support for responsive attributes. We need it to use ui! So if you git checkout that branch https://github.com/hoplon/hoplon/tree/responsive-layout-attributes and build-jar, then clone hoplon/ui and boot build, you should be able to start using hoplon/ui library.

You might want to boot run the library first, and play with the demos in what was originally intended to be the test directory.

Where are you at? How can I help?

The biggest deficiencies right now are:

1. the responsive layout logic leaks due to the fact we haven’t written the logic to detach the handlers,

2. the responsive layouts initialize to the largest screen size,

3. the box model hasn’t been applied to the body element within the window element itself, so there has to be another elem within it to use certain attributes,

4. the component libraries themselves need to be built out.

The next steps would be to properly implement checkboxes and dropdowns.

Help building out the individual component elements would also be much appreciated; we think the process is relatively straightforward at this point by emulating existing elements such as button or image.

Why hoplon/ui? What are the ideas behind it?

Here are some of the ideas behind hoplon/ui

Selector queries should be avoided due to their unmanageability and inefficiency. This is especially true if you build SPA with hoplon. We think there’s no reason to go fishing around in the dom matching on strings when we can just bind to variables (who knows what you might scoop up in a global tag soup). In hoplon, you have references to the elements in your code before they’re added to the dom. Just work with those instead. Much simpler. More performant. And you’ll actually get an error when something bad happens. We think you’ll find this to be a far more sensible way of doing things once you become accustomed to it.

It is more cohesive to associate attributes with the elements to which they belong; placing them elsewhere leads to a poor separation of concerns. CSS runs contrary to both of these ideas by requiring the use of selectors for ​everything​ and factoring styles out into a separate language entirely. Consequently, our approach to hoplon/ui is not to support them. We don’t need to use id or class attributes at all because we rely on the use of variable bindings instead of selectors.

For example, if you want to convert a bootstrap theme into one for hoplon/ui, you'd need to simply associate the stylistic attributes (like colors, font sizes, etc) with clojurescript vars like i do at the top of ui.cljs.hl then bind to them from your code. It is perhaps a bit more effort up front, but we can assure you from our own experience that saves us an enormous amount of time afterwards. It’s quite nice to get an error and a stack trace when you make a stylistic mistake because you used a var instead of a query to associate a style with an element.

Of course, if you’re being handed an html document from a server, and you need to mutate it afterwards, then you might need a selector to pluck the node out of it you want to alter. But when you’re building an spa, you already have those elements, so you can reference them using vars/variables instead.

Do you eschew stylesheets completely?

Absolutely! Why fish around in the dom for things with string matching queries when you could just bind to variables instead?

Good apis are supposed to be cohesive. External stylesheets and html smear similar concerns all over the app in different languages.

We’re supposed to separate different concerns, like presentation from data, not content from styles (whatever that means).

How do you then handle things like media queries and breakpoints?

The vectors are the media queries!

https://github.com/hoplon/ui/blob/master/tst/hoplon/ui-test-app.cljs.hl

In fact, unnecessary “queries” are exactly what we're trying to get away from. We think ui offers a better way of doing responsive layouts.

For example:

(u/button  
  :w ["100%" sm 200] :h 50 :click #(swap! things conj (count @things)) 
  "Add Thing”)

The vector after :w (width) means set the width to “100%” below the screen width contained in the var sm, and 200 pixels when the screen is above it.

This can be much more powerful than anything bootstrap offers for responsive layouts. Bootstrap gives you 4 hardcoded breakpoints that you have to deal with via stylesheets. This gives you an infinite number of them.

What attributes can window element take?

You can find those here: https://github.com/hoplon/ui/blob/master/src/hoplon/ui.cljs.hl#L551

How does elem work? Is it like div?

Each elem actually produces three divs: the outer is display: inline-table;, the middle is display: table-cell;, and then there's the inner block.

The outer div is used for sizing. The middle is used for stroke, borders, etc. The inner div is the thing itself, might be a button or whatever.

There are a number of motivations for doing this. The main one is the ability to include the margin in the size. For example, say you need four items across a page, this gives you the ability to simply set the width to 25% and get what you want.

Margins are implemented as the padding between the middle and outer divs. And it is the use of the tables and table cells that make actual vertical positioning possible.