search

TheProlog / prolog-use_cases

Use-case layer for Meldd/Prolog application.
0 stars 0 forks source link

Replace ActiveModel::Validation with Dry::Validation #28

Open jdickey opened 8 years ago

jdickey commented 8 years ago

Why? To avoid bringing in the world+dog bloat that comes with ActiveModel validation.

Dry::Validation is much smaller, better focused, and doesn't impose loads of stateful baggage on its client code. It does, however, impose a learning curve for those accustomed to thinking in traditional Rails-convenient ways as to require more upskilling than our schedule presently affords.

jdickey commented 8 years ago

Removed the The Glorious Future™ label, as we're planning on attempting this as part of ramping up the 0.10.0 Gem release ("Summarise Articles by Author").

That's right; even more bloat than ActiveModel::Validations by itself, during the transition. Assuming our first attempt is successful, conversion of existing use-case classes and supporting code will be accomplished as further work is done on them, up until such time as conversion is complete (whether before or after Meldd 0.5).

Why? Virtus, as great as it has been (and is), has succeeded beyond its present maintainers' apparent capability to keep up; issues and PRs are piling up, and the original maintainer, Piotr Solnica (blog, GitHub, Twitter) has moved on; there have been five small bug-fix releases since 1.0.0 shipped on 17 October 2013, and none since 18 March 2015 (a year and 15 days ago); and on and on.

More importantly, Virtus (and our form-object workflow based on it) are inherently stateful, which brings its own abundance of pain points, as several commits in PR #35 showed. The less reliance we have on persistent state (in what, remember, is running on the inherently stateless Web), the better.

jdickey commented 8 years ago

After a couple of days of research, we've established a few things with relation to Dry::Types and the other dry-rb Gems:

  1. We like them; they feel a lot "cleaner" and easier to develop with/reason about than Virtus, once you wrap your head around a few basic ideas; and
  2. There is no incrementalism involved in converting from use of Virtus to use of dry-types; you either convert everything within an isolatable subsystem of your project, or you don't;
  3. However, parallelism appears practical. As new subsystems/use cases are developed, they should use Dry::Types (and Validation, etc) rather than VIrtus and ActiveModel::Validation. For classes which must exist in both implementations, such as the current Prolog::Entities::ArticleIdent, a separate, parallel, functionally-equivalent class (hypothetically, Prolog::Entities::ArticleId or Prolog::Entities::ArticleIdent2) would be developed. Identifying multiple use cases that depend on such entities or other classes in closely similar fashion might well demonstrate a refactoring/extraction opportunity.
jdickey commented 8 years ago

Re-deferring this issue to The Glorious Future™. We love dry-types; we still intend to step away from the ActiveModel crack pipe but, especially considering that our non-trivial validation now is all hand-rolled code anyway, we're going to bite the bullet and do the rest of the job. dry-validations, as of their Release 0.2.3, simply isn't complete enough, stable enough, or well-enough documented for us to grab it on the run and keep going. We could survive doing without any one of those three; arguably any two; but going 0-for-3 isn't presently a survivable option.

/pinging Issue #42.