rml() that return source streams

[ftaiolivista]

First of all, congratulations on the project — it looks great.

I've been using Cycle.js for years and have been searching for a more modern alternative for new projects. While Solid.js has some interesting ideas, I personally don't enjoy its imperative style.

Rimmel (that I just discovered) feels exactly like what I’ve been looking for. I did have one idea I wanted to share.

Wouldn’t it be useful to have an alternative version of the rml() template function — one where the "sources" are specified using explicit textual references, and where the function returns a map of the generated source streams?

The goal here is to avoid the need to manually instantiate Subjects and instead promote a more unidirectional data flow.

For example:

flowhtml<input type="button" value="1" onclick="@source1" /> ${sink}

This function would return a tuple: [htmlElement, { source1: Observable<> }] — the usual HTML along with the observable source1.

What do you think about this approach?

[dariomannu]

Hi @ftaiolivista,

Thanks for the nice words :)
Let me try to get a better understanding of your idea and all its implications as I reply.
Some examples might help both ways, so will try to make use of a few along the way.

First off, let me add a few notes just to have some clarity on naming and avoid confusion.
If you come from Cycle.js, that has a very clean and truly unidirectional flow: given a component, sources come as parameters of the component-function, and the return value is a collection of sinks. That's really beautiful and I don't think we could replicate it in any way without essentially reinventing Cycle itself.

Now, Rimmel doesn't technically define or mandate what a component is or should look like. Whatever is in the docs comes from ergonomics-driven patterns emerged with use, so there is still a lot of freedom and flexibility with regards to future development.

The typical component pattern that emerged over time twists (challenges) the unidirectional aspect above a little bit by allowing both sources and sinks to come as parameters of a component-function. I found this to help ergonomics and to make code less verbose, but feel free to show me wrong on this.

It is just "syntactically" unidirectional in the sense that it's all top-down according to the syntax, both sources and sinks are parameters, but then we obviously know these are distinct "upstreams" and "downstreams":

const Component = ({ downstream, upstream }) => rml`
  <button onclick="${upstream}">${downstream}</button>
`;

Now, if we want to compose components, we start with our models:

// first we create a stream as a standalone "model" that
// can be reused anywhere and tested on its own:
const Counter = (initial) => new BehaviorSubject(initial).pipe(
  scan(x=>x+1)
);

Then we put everything together:

const Parent = () => {
  // you still create subjects, but you can "hide" the fact you do,
  // how about that?
  const c = Counter(0);

  return rml`
    <div>${c}</div>
    <div>${Component({ content: c, onclick: c })}</div>
  `;
};

This structure enables a component to always returns a template (an HTML string), this time in a way that's more similar to Solid and React.
Not saying this is in any way better or worse than what a Cycle component looks like, but it's at least a bit different.

If I had to draw a line between the two, I'd say Cycle components are designed to look more like streams themselves and Rimmel components are more like "HTML Monads" (rml is our unit function that enables us to lift anything by means of a template, then component composition itself is our bind operation, stretching the definitions a bit, but technically it seems to work).
We may need to examine the former pattern a bit more closely, at some point, and I'm not really an expert in Cycle.

Now, let me try to understand what you're proposing here, which is:

flowhtml<input type="button" value="1" onclick="@source1" /> ${sink}

This is just a template, but a component could be in fact structured in many ways, as you say, by having an alternative to the rml function.

const Unidirectional = (sink) => flowml`
  <label>
    <input type="button" value="1" onclick="@source1" />
    ${sink.HTML}
  </label>
`;

So, this new entry point would return something like { HTML, source1 }, more in line with what Cycle does.
If we want to compose, it would start looking as below:

const Wrapper = () => {
  const { HTML, source1 } = Unidirectional(down);

  return flowml`
    <div>
      ${HTML}
      <hr>
      Data: <span>${source1}</span>
    </div>
  `;
};

document.body.innerHTML = Wrapper().HTML;

Having this flowml function return all sinks makes it really convenient to have general-purpose components that can deal with not just HTML, but anything, really.

const SuperComponent = () => {
  const stream1 = ...;
  const stream2 = ...;
  const visuals = html`
    <div>${stream1}</div>
  `;

  const localStorageStuff = combine(stream2, whatever);

  return  { HTML: visuals, localStorage: localStorageStream };
};

This would be really, really great, as one of these supercomponents could also be used to sink LocalStorage, WebSockets, etc. I've been thinking about this problem for a long time, actually, and still exploring various variants and alternatives.

Now, apart from this, an other important observation comes up, too: if you look carefully, in either case, both in Rimmel and Cycle, at some point you do have to create some bidirectional streams. Typically in Cycle you do it in the parent, from the child:

const Parent = () => {
  const input = whatever();
  const { output, effects } = Child(input)
  return someTemplateOf(output);
};

In Rimmel the same is rather left with the child component:

const Parent = () => {
  const input = whatever();
  return someTemplateOf(  Child(input)  );
};

What I would argue is that in both cases you're doing the same thing, just in the parent vs the child.

The key takeaway is maybe unidirectionality just doesn't exist and we're forcing it somehow onto components, where in fact we may be better off embracing bidirectionality instead, for components?

The way it works now is that streams are typically unidirectional, components are bidirectional.
(Actually I'm changing this, too, in the upcoming TOPS, which will introduce bidirectional "duplex" observable streams, too, but I don't want to overcomplicate this thread for now, as it's already quite loaded :)

With regards to what you're saying about having to create Subjects every time, which I understand, the options appear to be:

• create separate input and output streams from the child in the parent, as in Cycle
• create input and output streams (or subjects) in the child, optionally bind to the parent (as we're doing now)
• have templates generate sources on the fly, via some DSL (the @source1 you mentioned).

The only problem with the third option is that you'd lose syntax consistency: source1 is just a piece of string, not a syntactical reference to a true entity. This means that in order to make it work we'd need to start adapting or create dedicated tooling, syntax highlight/check plugins for IDEs, maintain them, etc, which is not ideal. Look at where Angular ended up with its custom "magic" DSL.

So, by embracing bidirectionality, even if it may feel weird at first (after some time I promise it can really feel natural), we can preserve the syntax validity without any extra tooling. We can refactor/rename as normal without fear of breaking the code.
It's a trade off.

Bidirectional components were in fact a new discovery for me, too. It appeared to work, so I kept building on top of it and found they can very elegantly revive old, forgotten patterns such as the Event Adapter to help a better separation between models and views.

Nonetheless, I appreciate that the idea of the "Supercomponent" comes with many important benefits, so I'm happy to get involved in further research around your proposal.
Also, given how greatly Cycle built on top of unidirectionality is certainly worth bearing in mind and using as a source of inspiration, indeed.

What do you think could be a good use case for a few components connected together using Cycle's unidirectional flow? We could compare that for a start and see what comes out.

[ftaiolivista]

Thanks @dariomannu for the great answer, very interesting, you perfectly understood what I wanted to say.
I'll start by saying that I'm not primarily a frontend developer, but I deal more with backend, so take what I say with a pinch of salt.
As you say, maybe it's just a matter of habit, so I think I'll give a try having both the input and output streams as parameters of the function 😊.

I think I'll take some time in the next few days to do some use case experiments and maybe I'll share them with you in this thread.

In the meantime I've been thinking about the tooling problem. Could it be a solution to instantiate the sources directly in the template? It doesn't have any advantages compared to the current state of (rimmel, react, solid, etc...), in fact it has a more verbose syntax, but at least conceptually it seems more linear to me. And the Typescript correctly assign types out the returned streams.
But this is a very simple draft, not sure if could be possible with the more complex rml().

class Subject {}
class BehaviourSubject {}

function html<const T extends readonly [string, any][]>(
    strings: TemplateStringsArray,
    ...args: T
): [string, { [K in T[number] as K[0]]: K[1] }] {
    return [
        // fake html building
        strings.join('.'),
        //fake argument parsing
        Object.fromEntries(args) as { [K in T[number] as K[0]]: K[1] },
    ]
}

const [htmlStr, sources] = html`<div
    onclick="${['source1', new Subject()]}"
    onclick="${['source2', new BehaviourSubject()]}"
/>`

console.log(htmlStr)
// (property) source1: Subject
console.log(sources.source1)
// (property) source2: BehaviourSubject
console.log(sources.source2)
// Property 'source3' does not exist on type '{ source1: Subject; source2: BehaviourSubject; }'. Did you mean 'source1'?
console.log(sources.source3)

P.S.
In your opinion, could Rimmel already be usable in production? I see in the roadmap "Support for text nodes" but it seems to me that it is already included. Is SVG already usable in your opinion?

[ftaiolivista]

Ignore my code... What if I want to use same Subject for more than one event?🥲​

[dariomannu]

Sure, you can do that.
Normally you want to use a Subject or Behavior for any central stream of your application. E.G.: counter would be your main stream in a click counter component. Then you can just clone the button, keep the same references to the same stream and both buttons will feed and update from the same central stream, that's totally normal.
Subjects are great because you can attach any number of sources or sinks to them...

[dariomannu]

Looking forward to see what you come up with! Shout if you need help. Stackblitz is also amazing for these experiments.

| In your opinion, could Rimmel already be usable in production?
It is already used in a few production environments. It's all a spinoff project inherited and grown off a larger platform app.

It's obviously a young library with all that comes with it, but I'd say it can be used to power certain production scenarios, maybe some level of support could also help, but it shouldn't have any more bugs than the mainstream frameworks already have, so you trade innovation for a little bit of stability, as we might tweak the signature of a function or two, in case, but apart from that, it works and all you can do with RxJS (which is very mature and stable) you can do here with the same degree of confidence. Rimmel may seem a complicated thing, but all it does is just binding observable streams to the DOM, acting as a thin wrapping layer... If that sounds reassuring, happy to help out and support any production endeavours.

| I see in the roadmap "Support for text nodes" but it seems to me that it is already included.
There are a couple of cases that could be improved, and text nodes wasn't the highest priority. Should any template where you have ${some} ${thing} ${as} ${text} ${nodes} cause issues, the easy workaround is wrapping those in HTML tags <span>${some}</span> <span>${thing}</span>... which solves it and makes it more performant. The root cause is HMTL which doesn't provide any markup to denote text nodes, which is a bit silly. So we're left with filling the gap in a creative way rather than based on a standard backing it... an interesting conversation maybe for its own thread.

| Is SVG already usable in your opinion?
Haven't done too many things, but it appears to work, being the same reactivity and templating problem to be solved. Happy to help out on anything that comes up

[ftaiolivista]

Here an experiment. Two counters that can copy current value to each other. Just to test cross inter-component data share.

https://stackblitz.com/edit/rimmel-click-counter-jxwnnugd?file=main.ts

In this solution we assume each event stream comes always from a Subject (no Behavior or adapters, we can pipe what we need after).

With this system I think it is more natural to declare the template at the beginning of the component from which to obtain the streams that are transformed and then be returned or reused in the template itself (lazy/defear).

I also tested a sort of composition of components (see App).
At the end could work, but for sure the "standard" Rimmel give a more neat code I think.

[dariomannu]

That's really interesting. I've never seen a template defined first to be followed by logic this way inside a component.

It's a bit unusual, compared to most other flows where you define your state first (your streams, in this case) followed by the template, so that the template can be expressed as a function of state.

How did the idea originate? Not even Cycle does that as far as I remember...

[ftaiolivista]

Honestly I haven't seen it elsewhere either. Let's say it emerged as a natural solution while I was thinking about how to linearly obtain the output streams from the view. If we think about frameworks like React or Cycle where the view is a function of the state it is absolutely natural to have the view at the end. But with libraries that promote granular-update if you think about it it is less obvious. In fact in this case the view is a constant to generate the starting DOM. When this view is created listeners are connected to update its dynamic parts and callbacks to capture its events. In Cycle the creation of the source streams is completely decoupled from the view function. Which as a solution is fantastic (for example I can also obtain streams from parts of DOM created by third-party libraries with the same naturalness of code generated by the view function), but unfortunately it is certainly not the most performant (but by how much?!). Surely keeping the source streams synchronized with each change of the DOM is challenging since the two things are completely dissociated. With libraries like Rimmel or Solid we have instead that the connection of the source streams (or signals) and that of the sinks is contextual to the declaration of the view (or its subsequent modifications). If we think about HTML and vanilla Javascript, the HTML is declared first and the javascript is included later because it needs to have the complete HTML structure to be able to operate. So maybe it is not so "unnatural" to have the view first.

Demo version with better types declarion, here the source strings (even from child components), get the right typing.

https://stackblitz.com/edit/rimmel-click-counter-puwhces9?file=main.ts

[dariomannu]

can't see the link, maybe it's private?

[ftaiolivista]

Yes sorry, published