Better error messages

[rpominov]

As noted in #124 and #123 we currently have a bad situation with useful error messages and input checks in general.

I like very much how this is done in React. The error messages in it are very detailed and contextual. They describe what you done wrong, where to look at, and how to fix the issue.

Also React has a lot of deprecation warnings, so basically if your app has no complaints of deprecations, the switch to the next major version should be pretty smooth.

Also React has two builds for development and production, and production build has zero warnings and no checks itself (which is good for performance). Frankly I'm a bit speculating here, and not sure what is actually cut in the production build of React.

I think we should also have two builds like that. A thing to note here is that react is mostly frontend library, while Kefir may be usable in backend as well. I don't have much experience with backend development, and not sure what would be the best approach of controlling warning/errors for backend.

In Kefir there is a huge room for improvement here. We should chose a strategy, and then just work in this direction one step at a time. I'd borrow most of ideas from React, although maybe we'll need to adjust them for server side usage case.

[iofjuupasli]

I just had a problem with undefined observable in merge. The error stack is completely outside my project code (error on activation, whether mistake was on creation). So it's impossible to understand, where I made a mistake. In result, I've added check for undefined in kefir sources right in node_modules, and only then found where was my typo. It's really annoying to see error stacks that doesn't tell anything about real mistake.

[rpominov]

Sounds awful. It would be great if someone worked on this issue. Do you want to, @iofjuupasli? I could give a direction on where to start etc.

[asaaki]

I really like the error messages of Elm and Rust btw. Maybe also a good inspiration.

[Macil]

A thing to note here is that react is mostly frontend library, while Kefir may be usable in backend as well. I don't have much experience with backend development, and not sure what would be the best approach of controlling warning/errors for backend.

React is popular on servers too, and its strategy seems to work well: React only does run-time warnings if process.env.NODE_ENV !== 'production'. On the server, that just checks the environment variable at runtime. When people build a Browserify bundle containing React, then React's package.json specifies that the envify transform is to be used on React's own code, and the references to process.env.NODE_ENV in React's code get overwritten with the current value of the NODE_ENV environment variable at build time. (Then a minifier is able to strip out all of the literal comparisons and any unreachable blocks.)

[mAAdhaTTah]

The process.env.NODE_ENV approach seems to be the most common. If we're in agreement on that, there are a couple places where we can add checks that would help here, starting with the two indicated (concat & flatMap), which I'd be interested in tackling.