JSX Blocks like in ruby

[shaedrich]

As addressed another issue in the reactJS repo JSX Control Statements like this

<If condition={this.isUserLoggedIn()}>
  <UserPanel /> 
</If>

are a nice approach to have JSX-HTML between something like a conditional or a loop, but it would be even better if JSX could support something like this natively as it is used in Ruby:

[1, 2, 3].each do |n|
  puts "Number #{n}"
end

in templates:

<% if this.isUserLoggedIn()? %>
    <%= partial "UserPanel" %>
<% end %>

so in JSX it could look like this:

{if this.isUserLoggedIn()}
    <UserPanel />
{end}

[onyxblade]

You could try to write an ejs to vdom converter. I have previously done an erb to vdom one, it's simple if you already have an xml parser...

[texttechne]

This is no new proposal, but just another take on a long standing issue.

The current approach "the JSX team" seems to take is do expreesions. See:

• 88

• and especially #99
• ...

There are plenty of other tickets regarding this feature/enhancement.

[mindplay-dk]

4 years on and do expressions are still a stage 1 proposal - it's not happening.

Either way, JSX is custom syntax - there's no reason why you'd want that littered with do expressions, whether those were native to the language or not.

Meanwhile, the community keeps inventing template engines with custom syntax - I've known some people to shun JSX and React, literally because loops and conditionals "look bad", which, to be fair, they absolutely do:

const TodoList = () => <>
    {active
        ? <>Edit: <input type="text" onKeyDown={update} value={active.name} /></>
        : <input type="text" onKeyDown={add} value={name} /> }

    <ul>
        {todos.map((todo, index) => 
            <li>
                <input type="checkbox" checked={todo.done} />
                <span onClick={() => edit(index)}>{index}: {todo.name}</span>
                <a href onClick={() => remove(index)}>remove</a>
            </li>
        )}
    </ul>

    Total done: {numDone()} of {todos.length}
</>

Way too many parens and curly braces - and that extra <> and </> around the "Edit" title and input. It's not easy on the eyes, and it gets worse when you have several nested loops and conditionals.

It wouldn't take much to fix this - just some basic template-style syntax like we've known from server-side template languages from many years, and from many of the client-side frameworks with custom syntax today:

const TodoList = () => <>
    {#if active}
        Edit: <input type="text" onKeyDown={update} value={active.name} />
    {#else}
        <input type="text" onKeyDown={add} value={name} /> }
    {/if}

    <ul>
        {#for todo, index in todos}
            <li>
                <input type="checkbox" checked={todo.done} />
                <span onClick={() => edit(index)}>{index}: {todo.name}</span>
                <a href onClick={() => remove(index)}>remove</a>
            </li>
        {/for}
    </ul>

    Total done: {numDone()} of {todos.length}
</>

This doesn't necessarily need to be a new feature in terms of the run-time - I would be quite happy if this were just syntactic sugar for ternary expressions and .map calls, but those details are of course not even part of the JSX specification itself.

Now, personally, I write code all day long, and I can read the ternaries and callbacks just fine - but it's not very accessible to, for example, people who have worked primarily with server-side templating, people who are used to Vue or Angular, and so on.

I don't think people should pick template engines based on cosmetics, but, sadly, people do. And it sucks to have your manager tell you, "we picked Vue because the server guys have an easier time reading that", when there are many, more important reasons to pick a UI library.

I'm a minimalist at heart - but a little syntactic sugar goes a long way, when you're trying to sell somebody on an idea. In the eyes of your boss or manager (or just someone inexperienced) all of these UI frameworks do "basically the same thing", which is probably true to a degree, and if you don't know the deeper reasons to pick one or the other, syntax is very likely to color your immediate opinion.

I wish somebody would take this issue seriously.