Making the parser modular #48
Description
The Rimmel parser is relatively simple: it loops through template string literals and expressions looking for patterns to match, based on which it will decide how to treat each expression (as a source or a sink).
This works fine but it's hardwired to interpret promises, observables, arrays, etc.
It would be interesting to see if we could make it modular, so a distinct Observable parser would only deal with Observables/Observers, a Promise parser would only deal with Promises, and so on.
The obvious advantage is that we could selectively turn off reactive primitives we know we're not going to use or potentially introduce support for others, but making sure we don't sacrifice performance.
For now this is just an architectural/PoC task to see if we can do in a way that's the fastest and most elegant we can create, or a good balance in between.
A big part of the challenge is probably understanding how to keep the number of pattern matches or precalculated strings to a bare minimum, without recalculations and possibly avoiding too many nested function calls.
This should also be designed with a future template compiler in mind, that will need to work with the same parsing modules we want to separate out from here, or the new ones we're going to create.