[WIP][Breaking changes] Reducing complexity

[TrySound]

I have a few proposals and questions

• Remove template literal support from derive method and function
• Add template function combinator

  D.template`
  ${D.atom(1)} + ${D.atom(2)} = ${D.atom(1 + 2)}
  `.get();

• Remove property access with string or number from derive method
• Add prop function and method combinator with maybe and derivable argument support

  atom('any').prop('length').get()
  atom('any').prop(0).get()

• Remove regexp support from derive method
• Add match function and method with derivable argument support

  atom('abc').match(/a/g).get();

• Remove array destructuring since struct do something similar

  const i = atom(1);
  const [a, b, c] = i.derive([
  d => d + 1,
  d => d + 2,
  d => d + 3
  ]);
  console.log(a.get(), b.get(), c.get());
  const [d, e, f] = struct([
  i.derive(d => d + 1),
  i.derive(d => d + 2),
  i.derive(d => d + 3)
  ]).get();

Questions

• Should we support derivable arguments?

  atom().derive(atom(d => d.length))
  atom().prop(atom('length'))
  atom().match(atom(/\w/g))

• Do we even need complex and unreadable switch method combinator since it's not that hard to write own derivation?

  atom(1).switch(
  1,
  d => d + 1,
  2,
  d => d + 2,
  d => d
  )
  in opposite to
  atom(1).derive(d => {
  switch (d) {
  case 1: return d + 1;
  case 2: return d + 2;
  default: return d;
  }
  });

• Can we replace mOr with something static/fantasy land type like alt?

  atom(null).alt(atom(1));

• Do we need both named and default exports in entry point? I guess named exports can be resolved everywhere.
• Can we rename .derive and .mDerive methods to map and maybe mMap to separate behavior from derive function and remove explicit injections (are they some political decisions?)

  const coef = atom(2);
  atom(1).map(d => d + 1);
  atom(null).mMap(d => d * coef.get());
  // previosly atom(null).mDerive((d, coef) => d * coef), coef);

• Any ideas about the future of derivable?

P.S. After this PR+discussion I'm going to rewrite API docs.

/cc @ds300 @andreypopp @friedbizkvit

[andreypopp]

I think it's a good idea in general. I'm all for reducing the API surface, especially removing overloads from methods and making them more "typeable". It would be cool to see how is API going to look like in terms of typings.

[TrySound]

Also should we introduce deprecations for the next release?

[ds300]

Sure go ahead. These seem like good changes.

Should we support derivable arguments?

Maybe not. That's a bit too black-magic-like for my tastes these days.

Do we even need complex and unreadable switch method combinator since it's not that hard to write own derivation?

No. Get rid of it.

Can we replace mOr with something static/fantasy land type like alt?

Sure

Do we need both named and default exports in entry point? I guess named exports can be resolved everywhere.

Nope. Go for only named.

Can we rename .derive and .mDerive methods to map and maybe mMap to separate behavior from derive function and remove explicit injections (are they some political decisions?)

Hmm this I'm not sure about. I definitely prefer the word derive to to the word map which has all kinds of other connotations, even in the JS ecosystem. Injections can be removed though. I think I was the only person who really used that.

:+1:

[TrySound]

Okay. The next series

• Do we need template, match (pretty simple), prop (hard to type, with map easy to type)
• Do we need functional map, mMap, match, prop versions
• Do we really need then, mThen instead of simple ternary?
• Should we deprecate all stuff before removing or burn it all?
• I found mOr, mAnd, and, or typed with boolean output. This case isn't so useful. mOr can be renamed to alt. How can be others useful? Maybe remove?)
• Same question for not

[ds300]

Do we need template, match (pretty simple), prop (hard to type, with map easy to type)

I guess not.

Do we need functional map, mMap, match, prop versions

Nope.

Do we really need then, mThen instead of simple ternary?

Nope.

Should we deprecate all stuff before removing or burn it all?

Burn it

I found mOr, mAnd, and, or typed with boolean output. This case isn't so useful. mOr can be renamed to alt. How can be others useful? Maybe remove?)

Sure, remove everything but alt.

Same question for not.

Remove that too.

Love what you're doing here. I added all this complexity because I wanted DerivableJS to be a DSL-like tool, but everyone else who used it just wanted the reactivity and didn't care about the DSL stuff. Now that I'm older and more experienced I see the value in keeping as much logic in the host language's primitive syntax forms as possible. Can't wait to try using DerivableJS again after you're done!