reversing order of operator? about solid

[ryansolid]

Yeah.. this is a functional convention I picked up from my time with RxJS. Essentially I wanted to create an extensible operator pattern that didn't require hoisting the Signals. For info on the idea look at Let-able or Pipe-able operators in RxJS.

In basic as you add more operators to the Signal object you need to wrap new versions or add methods to it's prototype. This is a mess if not all applications have the need for all the operators. So why the order? To make them functionally composable.

// classic example
signal.map(i=>i).filter(i=>i)

// not hoisted
filter(map(signal, i => i), i => i)

// composable
filter(i => i)(map(i => i)(signal))

However the latter 2 examples lose the sequential order of operations. However, as you can see operators reduce right in the last example which lets you write it as:

compose(
  map(i => i),
  filter(i => i)
)(signal)

This returns to the sequential order. I've included a pipe operator which lets you write it as:

pipe(
  signal,
  map(i => i),
  filter(i => i)
)

So I could also export non-pipeable operators, but they do come with a few really nice benefits. Like you can create new operators by composing existing ones, or by applying arguments to existing.

const double = map(i => i * 2);

// somewhere else...
const doubledSignal = double(signal);

The operators sections gives some examples.

[ryansolid]

I didn't finish my thought here. So to your example you can use pipe.

pipe(() => props.state.todos.length > 0, when(() => <TodoFooter {...props} />))

The operator naming perhaps needs work.. When suggests condition and Each suggests the iterated, when in fact both are just the mapping function.

For single operators I tend to not use pipe since the args are flat enough.

I might be weighing the importance of extendability too far. But Signals are a lot like simpler RxJS observables, and the transformations they can represent in a declarative way are very powerful. You can wire them up in a certain configuration and then they run themselves. So I see a lot of benefit for making it expandle. S has the S-Array library but the hoisting is super awkward since Signals are just functions etc. Every person who wants to make a new operator needs to do a lot of work. WIth this approach anyone can write Signal operators, and throw it up on Github. And anyone can import the ones they want to use and then just use it.

[ryansolid]

While I am a very big proponent of functional programming patterns and think this is the correct way to develop operators out for Solid I think rendering is a special case and I've made specialized constructs now for loops and conditionals. In so I've removed the operators from the core. While I could see a separate package to support them where needed I think it might be completely unnecessary with the new API. With Proxies doing away with the need for specialized operators for Arrays and rendering being a special case I think this is probably something more for the implementor. I may revisit in the future but for now operators are gone.