# Why Control Flows Should NOT Be In XHP

DevFeed: [Why Control Flows Should NOT Be In XHP](<https://devfeed.tech/articles/why-control-flows-should-not-be-in-xhp-22032.md>)

Original publisher: [Read original article](<https://codebeforethehorse.tumblr.com/post/36089777404>)

Author: Codebeforethehorse

Published: 2012-11-19T21:58:00Z

Content type: opinion

Language: en

Sources: [Stefan Parker](<https://devfeed.tech/sources/stefan-parker.md>)

Topics: [PHP](<https://devfeed.tech/topics/php.md>), [Code](<https://devfeed.tech/topics/code.md>), [HTML](<https://devfeed.tech/topics/html.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [html](<https://devfeed.tech/tags/html.md>), [php](<https://devfeed.tech/tags/php.md>), [xhp](<https://devfeed.tech/tags/xhp.md>)

## AI overview

The article argues that control-flow constructs should not be placed in XHP. It explains that conditionals instantiate both outcomes before rendering, while loops can create unnecessary wrapper objects and produce results that differ from expectations when evaluated later. XHP should remain focused on HTML rendering rather than acting as a programming language.

## Source excerpt

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? $panel = userIsAdmin() ? <ui:admin-panel /> : <ui:user-panel />; $root = <div>{$panel}</div>; $root = <div> <x:if cond={userIsAdmin()}> <ui:admin-panel /> <ui:user-panel /> </x:if> </div>; So much more efficient, right? Wrong! There's a big difference between these two practices, can you think of it? Putting the conditional in XHP actually instantiates both outcomes. Because the conditions are only evaluated on render, they need to be instantiated even if they're just going to be thrown away later. Plus, it may seem readable now, but what happens with nested statements? <x:if cond={isLoggedIn()}> <x:if cond={isAdmin()}> <ui:admin-panel> <ui:user-panel /> </x:if> <x:if cond={canSee()}> <div> <ui:post /> <x:if cond={canComment()}> <ui:comments /> </x:if> </div> <ui:cannot-see-content /> </x:if> <ui:loggedout-page /> </x:if> This is getting complicated quickly. XHP is really good at giving you an abstracted view at what the generated HTML structure will be, but this completely breaks that ability. I have to parse and separate out in my head the pieces that will be rendered. But really, you're creating tons of objects just to throw them away, that should be enough to never do this. Ok, so that eliminates <x:if> and <x:switch>, but what about <x:for> and <x:foreach>? They won't instantiate anything extra so we should be good, right? Well, let's take a look at an example. $list = <ul />; foreach ($items as $item) { $list->appendChild(<li>{$item}</li>); } $list = <ul> <x:foreach set=