Juice 2
Warning Theese are just my ideas written in czech. Reading for own risk
Lexer vyhodí ast, to se hodí do parseru který rekurzivně vytváří vystup
Lexer
Postupně prochází a podle TokenKind vrchního itemu v pomocném stacku generuje ast.
STACK JE CESTA KE STROMU
K rozpoznání značky stále regex aby byly možné vlastní regexy.
Token
- Kind - druh, enum
- Name - jméno toho tagu (h1, if, nebo nic například u {{}}), ?string
- Content - obsah tagu (atributy, php v direktive,...), ?Token[]
- Children - děti uvnitř tokenu, ?Token[]
- Position
PhpLexer
Ta věc co lexuje obsah direktiv. Opět stejné řešení jako u lexeru, prostě podle vrchu stacku pracuješ s tokenama, aby sis to usnadnil pouzijes nativní tokenizer.
TODO doplnit podporované tokeny
Parser
Jede token po tokenu pro každý se nějak chová a každý kind má svoji třídu která ho parsuje. Zároveň rozpoznává kontext, pokud je tokenkind attribute například tak se context nastaví na Attribute a parsuji de jeho children.
Alpine
Zároveň to umí vlastní atributy takže něco jako alpine ale s tím rozdílem ze my pošleme jen to co je potřeba protože vykompilujeme potřebný kód.
Pokud tohle ctes tak je mi te líto nebo pokracuj Majkele.
Pak možná překlady
A dal nevim
Každý tokenkind a kazda direktiva je svoje trida
pravdepodobne stejna taktika jako u htmlispu akorat imperativne
pouzit or. asi nejlepsi alternativa pro >>=
mozna lexer parser transpiler lexer do pole parser do ast transpiler do php/js
{@\foreach $foo as $bar} {$bar} {/foreach} fusion between svelte, latte and blade :800iq:
we could keep some juice-legacy syntax
also components
directives in config
If I use custom LL parser machine (🎰) I can let users write custom syntax! (and also let them add stuff like operators with high-level syntax)
add nested layouts, meaning that layout system would be written from start to accept this.