isomorphic active-record mode

[catmando]

There are many active-record methods that are not implemented in hyper-model.

In some cases not having these methods can cause strange failures that are hard to diagnose.

Instead we should run in one of three modes:

hypermodel_compatibility_mode = :warning # or :strict, :ignore

This can be set in each active record class.

:warning prints warnings on the js console and rails log when these methods are used, :strict fails violently on either server or client and :ignore does nothing.

Furthermore for CRUD operations which currently return promises we should add async variants like asave, adestroy, aupdate etc... these will have the same behavior on server and client. In strict mode the normal save, destroy, update, etc methods are removed, so you have to used the async variants. In warning mode you get a warning if you use the normal variants.

[janbiedermann]

Async CRUDs are great to have to be isomorphic +1

About the modes: I like :strict, because that makes development and testing easier.

What about to set Models, that are moved to app/hyperloop/models in strict mode by default? Thus maybe require them to include or inherit from a Hyperloop::IsomorphicRecord? This way normal AR models can be left alone and behave like usual and models that are used isomorphic are enforced to behave or raise. In that sense, when a model is requested from the client, server checks if the model is a Hyperloop::IsomorphicRecord, if it is, ok, if not, raise -> Model not isomorphic It makes clear to the developer, you are leaving AR zone, welcome to isomorphic zone :) -> Difference between these two zones is explicitly expressed and sets the thinking/development process straight.

[illogikal]

+1 but in spirit of correct naming I would prefer async_save, or hyper_save or something like that...

[janbiedermann]

it looks to me, like this ReactiveRecord DummyValues are not really that good of an idea and can be very misleading. Wouldn't it be better to get the real value, and if that is not possible, a promise? meaning async methods like reactive_get will deliver promises only. Then one can handle this with .then …, yes, would break AR semantics, but it does that anyway, and wouldn't be isomorphic when using AR on server RR on client. The original thinking maybe was to use the values in the view and on resolve update the view and everything is shiny. Being used to AR, people use values for further AR-things and that will fail then. for being isomorphic instead of Model << ApplicationRecord doing Model << ReactiveApplicationRecord << ReactiveRecord would keep isomorphic behaviour consistent, and would need an RR to AR adapter on the server. Our previous idea of just providing async methods doesn't seem to be sufficient.