Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
This is a thought experiment for how Raptor apps might be designed. The module hierarchy is: Routes Injectables .current_user .post_params Interactors CreatePost PostSaved ValidationFailure Models User AnonymousUser Post Records User Post Responsibility breakdown: - Routes are the same Raptor routes as ever. They can route out to different actions/redirects based on the interactor's response. - Injectables provide objects for Raptor's implicit DI. For example, the `post_params` injectable does what it sounds like, so that Interactors::CreatePost can take a `post_params` argument without worrying about where it came from. These are class methods directly on the Injectables module. - Interactors contain the application's logic. They return (or raise) response models that are usually defined directly in the interactor's class (or maybe from a shared location if appropriate). - Models wrap database records to provide simple mutations and data wrappers. For example, Post#publish updates the published flag and saves. These don't necessarily map to records one-to-one. For example, the AnonymousUser model exists to avoid a nil current_user, and doesn't map to anything in the database. - Records are straight-up database records. No methods; just field definitions. This hierarchy doesn't correspond to the file layout. Instead, files are grouped by topic. For example, posts.rb contains Interactors::CreatePost, the post_params injectable, and the Post model. Modules in the system will be reopened many times as code is loaded, giving us lasagna files instead of ravioli files.