API Design Decisions

[semmel]

Just some quick observations/questions:

• Regarding the new static function signatures it would be better for function composition to have the order of parameters in this way: least changing parameters first, data last. This way the functions can be curried and partially applied to allow composing function pipelines on the stream. E.g.

  const
  isEven = x => x % 2 === 0,
  add = (a, b) => a + b,
  square = x => x * x;
  pipe(
  filter(isEven),
  map(square),
  scan(add, 0)
  )(sequentially(100, [1, 2, 3, 4, 5, 6…])
  // -> 4, 20, 56, …

  See also Dr. Boolean's Mostly Adequate Guide or his hallmark talk Hey Underscore, You're Doing It Wrong!

• I like that the library no longer deals with errors. (Burden of the user, could use Eithers as values). 👍🏻

• It's also great that Properties and Atoms always automatically skip duplicates 👍🏻

• What about atomic updates?

  const
  id = x => x,
  n = sequentially(100, [2, 1]),
  p = map(id, n),
  q = map(id, n);
  combine(add, p, q); // -> 2, 4 or 2, 3, 4 ?

[raimohanska]

Thanks for the feedback and suggestions! I'm glad you found good things here!

The API is in the works and a pipeable API would be nice IMO too! (even the readme says this) Currently the lib is in a "could this work?" phase and the API will definitely have to be shaped for (subjectively) optimal shape in case I (we) are gonna make this an actual library.

At this point, I've not included a general atomic updates system. I'm on the fence whether it would be an asset. In Bacon it has certainly made things very complicated and the library's behavior hard to reason about even though it mostly works great due to extensive testing. What I have in Lonna now is StatelessProperty which is used for Map and Combine (the common state-decomposition operators in UI state management). Stateless Property delegates it current value to it's source(s) so it will avoid invalid states in diamond-shaped setups. That just might be enough.

[raimohanska]

The API is now pipeable, with some exceptions like view and combine which are most convenient in their current form in my opinion. Here is some example code with the current API.

The reason for keeping view in Observable-First order is that type inference works way better this way. Also, when writing UI code you'll want minimal boilerplate. Consider

L.view(prop, "name")}

versus

prop.pipe(L.map((x: Thing) => x.name))

In the latter form the type Thing cannot be inferred.