majg0/nxtpression

Observable-based template expression library

nxtpression's Issues

Support null and undefined

Needs tokens, parsing, compilation and a test each

object property shorthand notation

Add support for the {{ { property } }} shorthand syntax

Ensure expression groups work

There is some already existing code which is supposed to handle grouping expressions with parentheses; add extensive tests for this and make sure they pass

Logical branching

My suggested syntax is

a | getRecord() if !isMatch() { discard() } else if isBad() { error() } else { process() } | logResult()

I.e. this would kinda compile to

let b = getRecord(a)
let c
if !isMatch(b) { c = discard(b) } else if isBad(b) { c = error(b) } else { c = process(b) }
logResult(c)

For this we need some new tokens;

• if ("if")
• else ("else")
• ! ("invert")

I also introduce scopes via curly braces. For now these only have to be supported after if/else.

Needs new tokens, new parsing and new compilation code on top of tests

Revamp throwOnUndefinedVariableAccess

Rename setting to onUndefinedVariableAccess and take representative string values instead in order to ensure extensibility.

• throw
• IGNORE
• forward

Add tests for all relevant functions for throwing or not.

Update docs

Lambda expressions

Here's a silly example one would probably never write:

{{ nums | reduce((a, b) => add(a, b), 0) }}

because they would just use an add function capped at two arguments if they needed this capability.

Hold off on implementing until need arises.

Augment compile errors with source

• Pass source to compile
• Make ast nodes contain the token(s) they were generated from?
• Use the util error reporter in order to throw helpful messages

Document surface area in readme

• usage from npm to code
• api reference and usage (if big, separate file with link; only synopsis in readme)
• compact list of available syntax e.g.

// number
{{ 3.141562 }}

// string
{{ "hi" }}
{{ 'hi' }}

// property
{{ a.b }}
{{ a[b] }}

Array and Object spread operator

• Array spread {{ [...arr, item] }}
• Object spread {{ {...obj, key: value} }}

Optional RxJS dependency + manual runtimes

• introduce a secondary package-independent compiler frontend, compiling templates for functions which report not just their values but also their asynchronous dependencies, for manual data and re-run tracking
• add separate tests file for this frontend
• turn rxjs into a peer dependency
• update documentation in accordance

Standard Library?

• number/math (isNumber, min, max, floor, ceil, sign, clamp, add, sub, div, mul, pow, isNan, isFinite)
• logic (if, not, ternary, match)
• string/regex (isString)
• iterable (slice, map, filter, reduce)
• date
• object (isPlainObject, keys, entries, values)
• boolean
• array (isArray)
• comparison

Monaco syntax highlighting

Task 1 (research for bonus scope)

Given that nxtpressions are bound to exist in JSON and JavaScript strings, would be very good to also explore the possibilities of including this inside a JSON editor - whether actually A) an extension of the JSON version editor of Monaco's or B) a wholly new JSON editor - I don't know. But it would be badass, so we should definitely investigate.

A quick look indicates we should be able to use https://microsoft.github.io/monaco-editor/api/modules/monaco.languages.html#setmonarchtokensprovider ; That said, https://stackoverflow.com/a/47085671/8020381 so might need to go with option B.

Here's a way to achieve it microsoft/monaco-editor#252 (comment)

Task 2 (current scope)

Approach A) Write a language syntax definition for the Monaco editor (used by VS Code among others). This can be accomplished using Monarch: https://microsoft.github.io/monaco-editor/monarch.html

Approach B) However, not sure we need this - since we can already tokenize ourselves, maybe it's easier to just parse strings to detect templates and traverse the ast to put the colors in the editor. Here's some more info and perhaps a good idea of debouncing microsoft/monaco-editor#851 (comment)

Probably favoring approach B

Self-referential object templates?

Should an object template be able to reference a path in itself?

For example:

{
  a: '{{ 1 }}',
  b: '{{ a }}'
} // => { a: 1, b: 1 }

Rework arithmetic ops

Consider today’s
a | b() + 1
Or worse
a | (b() + 1) * (2 * 3) / (c - 4)
It’s far from obvious how to properly compile this. (How does b get its a arg? In what order does things evaluate?)
We should drop support for this.

Consider instead
a | b() | +(1) | *(2, 3) | /(c | -(4))
Or
a | b() | add(1) | mul(2, 3) | div(c | sub(4))
This is much cleaner and easy to follow as for understanding what happens. Also way easier to generate code for.

I’m thinking we should go for both +(1) and add(1) styles. For that I think we need to change how an identifier token is regexed, right now the + char isn’t there e.g.

Tasks;

• write a test for the nonstandard chars and make sure it passes while not breaking stuff
• remove any trace of arithmetic ops and groups (in tests and the tokenize, parse and compile modules)