HeapsIO / domkit

CSS Components based strictly typed UI framework for Haxe
MIT License
84 stars 20 forks source link

[Regression] Text node issue #21

Closed rcstuber closed 4 years ago

rcstuber commented 4 years ago

Starting with commit (https://github.com/HeapsIO/domkit/commit/98543014786b89d5683be1520452e4908cd84c1a) support for inline text is no longer working as expected and gives aInvalid Code Block error.

Example:

static var SRC = <somediv>
     Some Text //<--- no longer works
</somediv>
ncannasse commented 4 years ago

This is intended, as we support <somediv>for( x in arr ) <a/></somediv> and have plans to support more code constructs at this toplevel (var and if for example). Also, usually inline texts should be usually localized, requiring some macros. You can still use domkit macros for that, for instance @text("Some Text") that will generate your custom component

rcstuber commented 4 years ago

Ok, I understand your plans going forward. But the intention should at least be announced/documented somehow in the commit message, as it's really a breaking change and the documentation (https://heaps.io/documentation/domkit.html) updated in that regard. I know how much we all love doing that ;-)

kLabz commented 4 years ago

Does it really have to be top-level? Adding such restrictions on plain text for a UI description "language" seems harsh to me (even though I agree that text should usually be localized, but don't think localization should be enforced like that).

With tink_hxx we have control structures as "pseudo-tags", which does not compete with plain text (but would shadow components named for, switch, case, if, else, .. which should be mostly fine?).

Another way of supporting both code and plain text would be to have code blocks inside { ... } (or ${ ... }), making it closer to code in haxe string interpolation.

kLabz commented 4 years ago

Another way of supporting both code and plain text would be to have code blocks inside { ... } (or ${ ... }), making it closer to code in haxe string interpolation.

Just re-read the docs and this is actually already working like that, and documented:

<flow>
${ for( t in tiles ) <bitmap src={t} id="btns[]"/> }
</flow>

Is it really worth it to break plain text (with bad error handling) just to be able to do the same thing (well less, new syntax only supports for atm) without ${}?