3 ms·
Well, this is weird. A few hours ago, I tweeted how I dislike Rails::Engine(https://twitter.com/pothibo/status/433595617383047168 https://twitter.com/pothibo/st
by pothibo 13y ago
Well, this is weird. A few hours ago, I tweeted how I dislike Rails::Engine(https://twitter.com/pothibo/status/433595617383047168 https://twitter.com/pothibo/status/433595617383047168). I'm going to write a post about it sooner or later but here's a few reasons on top of my head why I dislike them:
- Rails' use of folder for autoloading can encapsulate part of your application like engine does. (app/models/admin/post.rb vs app/models/post.rb)
- Different dependencies will turn on you in the long run. You're shoveling the problem ahead.
- Routing between different engine is cumbersome because of lack of autodiscovery (You can't know easily at run time which engine is mounted)
- bleonard 13y agoI would love to read it. I noted and am worried about the dependency thing, though I think that would still happen anytime they were all in the app/bundler regardless of engine use or not. For "knowing what's enabled" we use the BootInquirer I mention, though we've never had to to know at runtime. The interesting stuff comes up when we have to sync the routing to our load balancer, which we haven't fully automated, though it seems possible.
- shageman 13y agoTo your points: - yep. It is unfortunate. Always stick to the default folder structure (subfolders for modules) to prevent any weird interactions among engines and between engines and the main app. - Prevent this by not allowing this. You would not have different dependencies within one Rails app and you can't have it with a component-based architecture. - Routing between engines should be much less frequent than routing within. A perfect case for preventing unnecessary dependencies by creating "engine routing intrefaces"