search

tsers-js / core

Transform-Signal-Executor framework for Reactive Streams
MIT License
145 stars 4 forks source link

TSERS 2.x roadmap #23

Open milankinen opened 8 years ago

milankinen commented 8 years ago

I'm creating this PR for TSERS 2.x release discussion and planning.

My proposed changes for 2.x are documented in roadmap.md document in this branch. Please feel free to comment and discuss about the proposed changes in this PR!

milankinen commented 8 years ago

See also issue #18

codecov-io commented 8 years ago

Current coverage is 97.98%

Merging #23 into master will not change coverage

@@             master        #23   diff @@
==========================================
  Files             1          1          
  Lines            99         99          
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
  Hits             97         97          
  Misses            2          2          
  Partials          0          0

Powered by Codecov. Last updated by b1b5d2b...1330375

ghost commented 8 years ago

I'm agree with your proposed changes. They look very nice! I'm looking forward to TSERS 2!

TSERS = expressiveness + scalability = fun + productivity

typeetfunc commented 8 years ago

TSERS components would only return {DOM, Eff} pair

What about not-DOM application(server-side, console, native application)? Might be worth allow the user to define the main application Effect(DOM for web, HTTP for server-side etc.)?

milankinen commented 8 years ago

@typeetfunc Very good notice. Personally I wouldn't recommend TSERS or Cycle as a server-side architecture because request-response is point-to-point by nature, hence e.g. promise pattern works much better for it. But CLI...

How does for example {UI, Eff} sound? UI would then represent either DOM or CLI depending on the application type.

typeetfunc commented 8 years ago

@milankinen But why? Firstly Observables more general and more appropriate for implement architecture with first-class effects(cycle, tsers, ngeffects as examples). In second, modern web is very "real-time" - websokets, streaming, server push, subscribsions. Look at Appolo, feathers, horizon - all of them used observables for managing subscriptions. I believe that you approach is very general and architecture with first-class effects/events is future of all "real-time" applications.