Code Before the Horse

A blog about XHP, UI, and horses

1 note &

Contexts Added to XHP

I just added a new feature to XHP to allow you pass data automatically through the hierarchy of an XHP tree being rendered. That’s kind of a mouthful, but what it means is that you can set context (which is just a map of key/value pairs) on some parent element, and that context will be available on all rendered elements and their children. Let’s take a look at some examples to better understand where this would be useful.

Read more …

Filed under xhp

1 note &

Rendering ONLY Children in XHP

My last post, Rendering NULL in XHP, surprised a bunch of people by the use of extending :x:primitive to handle children rendering before the parent’s rendering. So I thought I’d quickly discuss another useful trick you can do by extending :x:primitive, this one deals with getting just the children from elements that alter their children before rendering.

Read more …

Filed under xhp

1 note &

Rendering as NULL in XHP

There are some at Facebook who have argued against returning null when rendering an XHP element. In fact, it’s actually against Facebook’s standards now. Personally, I prefer to structure my code to return null in XHP, but there definitely are pros and cons. I’ll cover the situations in which you might want to return null and what the alternatives could be, and then you can decide for yourself.

Read more …

Filed under xhp

0 notes &

When and How to Use XHP Categories

I remember when we first added the children keyword to XHP. We had the problem that validating them was really cumbersome. Nearly every element was valid inside a <div> but not all (for instance <meta>). Listing out every valid child wasn’t very elegant and certainly would cause problems for custom XHP components. Fortunately, the HTML spec categorized elements just for this purpose. Grouping elements into “block” or “inline” categories made validation far simpler. But if you’ve used XHP you might be wondering, “Why have I never needed to define my elements as inline or block before?” Well, the answer lies in how XHP renders an element tree. First it will render down all your custom elements into their eventual HTML primitives, then it will render the entire HTML primitive tree into a text string. The key here is that there are actually two passes, meaning XHP validates children in two sets: your elements first and then core HTML elements second.

Read more …

Filed under xhp

3 notes &

Building a Good UI Framework with XHP

This is the article I wanted to write ever since I started this blog. XHP is a really powerful tool, but like any tool you need to know how to use it for it to be really effective. Facebook has built a very powerful UI framework on top of XHP, but we had to change the way we think about object patterns to do it. I’ll get into that in a bit, but first I’m going to jump right into the most important feature of Facebook’s UI library: attribute forwarding.

Read more …

Filed under xhp

0 notes &

Data- & Aria- Attribute Support Added to XHP

Last night I added data- and aria- attribute support into XHP. I baked it into :x:composable-element directly instead of relying on previous methods which only added it to :xhp:html-element. I did this for a few reasons. First, I didn’t like the idea of getAttribute() and setAttribute() not being final within :x:primitive. Secondly, if you want to build a UI framework on top of :x:element that forwards attributes, you’d need to un-final getAttribute() and setAttribute() in :x:element too, and duplicate all the logic in :xhp:html-element into your UI framework. No, I feel it’s much better to have the slightly nuanced behavior of always allowing data- and aria- attributes on XHP, even if they won’t do anything on custom :x:element extensions by default (HTML elements render them just fine).

You can download the latest source at: https://github.com/facebook/xhp.

Filed under xhp

2 notes &

Why Control Flows Should NOT Be In XHP

About every six to nine months or so, an engineer at Facebook tries to add a control structure into XHP. These usually come in up to four flavors per diff: <x:if>, <x:switch>, <x:for>, and <x:foreach> (and occasionally <x:map>, which really is just a different <x:foreach>). A diff is submitted and invariably a long discussion ensues before the diff is eventually abandoned. I have to admit, it is tempting sometimes. I mean, we can keep everything in a single XHP block. How much cleaner is that?

Read more …

Filed under xhp

1 note &

The Difference Between :x:element and :x:primitive

I was recently asked to clarify the differences between :x:element and :x:primitive, and when to use each one. It’s actually pretty simple; the basic rule of thumb is this: always use :x:element. If you’re only doing simple things in XHP you can stop reading now, but for the rest of you I’ll get into the rare instances where you might use :x:primitive.

Read more …

Filed under xhp