Hacker News Reader

Comment by benatkin | Hacker News Reader

Interesting that the custom element appears to just take a single JavaScript object as a parameter:

  <Board {game} />

In JSX this would be either:

  <Board game={game} />

or:

  <Board {...{game}} />

This is almost as ergonomic as JSX except for attributes like checked where the value is omitted. It might encourage some refactoring, compared with React, because the thought of putting attributes in a variable and adding them as a spread might occur more often when seeing an object being passed in.

At any rate, I recommend looking at the code example linked in the post, or watching the video. Otherwise the post is pretty low in information, as the top comment at the time of writing this suggested. https://github.com/jesseskinner/svelte-tic-tac-toe

View on HN

In Svelte,

  <Board {game} />

Is just a shorthand for:

  <Board game={game} />

Spreading also works, although it's not nearly as used:

  <Board {...{game}} />

Boolean HTML attributes like "checked" can be used with boolean variables as-is:

  <input type="checkbox" {checked}>
  <input type="checkbox" checked={someBoolean}>

I highly recommend anyone to go through the tutorial (at least once Google Cloud Run issues are solved) to get a feel of how things work together.

Oh, I see. Looking further into the docs, I see that a JavaScript expression can be added inside an attribute string:

https://svelte.dev/docs#Attributes_and_props

It seems like a neat design.

Am I the only one who would rather write the following instead of JSX?

    Board.draw(game)

    drawBoard(game)

Not sure how that's a preference without any further context about how you plan on writing the rest of the client. For all we know, both of those functions return <Board {game} />.

> For all we know, both of those functions return <Board {game} />.

No.

Well, that's kind of my point. Making a superficial aesthetic change doesn't explain what you're actually preferring over JSX. Nor do you seem interested in explaining it.

> Nor do you seem interested in explaining it.

The lack of questions and the relentless downvoting makes me believe nobody's interested in hearing my explanations.

Well you might like Hyperscript or Elm, those are two approaches that work quite well using simple function calls.

The thing with JSX is introduces a syntax that is familiar to the rendered output (which is the status quo), and there's a relatively clear visual separation between the declarative and imperative parts; which is hard to enforce in pure JS.

The problem with JSX (and it's the same problem with all declarative languages) is you have no control over the control flow.

That's because JSX doesn't concern itself with control flow; it's not its job. Your framework has that job.

No, that's my job.

I'm struggling to think what kind of control flow you're looking for when specifying a document consisting of a tree of components. If all you want is a way to render one nodeset over a different nodeset at runtime then you can easily do that by setting that behavior in the relevant component.

Reply on news.ycombinator.com