ruby-hyperloop / hyper-react

The project has moved to Hyperstack!!
https://hyperstack.org/
MIT License
285 stars 14 forks source link

Generate and inherit from ApplicationComponent #227

Open sfcgeorge opened 6 years ago

sfcgeorge commented 6 years ago

Similar to Rails by default generating an ApplicationModel < ActiveRecord::Base class which all AR generated classes inherit from User < ApplicationModel; we should generate an ApplicationComponent class and the component generator should generate components inheriting from that. E.g.

class ApplicationComponent < Hyperloop::Component
end

And then a component:

class Greeter < ApplicationComponent
  render do
    "Hello, World!"
  end
end

This way you can add useful methods to your app's ApplicationComponent without monkeypatching Hyperloop or messing around with mixins.

I've just set up this structure in our app and it works great.

janbiedermann commented 6 years ago

Thats one of the first things i did, create an ApplicationComponent. It seems very natural.

explainer commented 6 years ago

I just checked through my 12 different component classes I have in my hyperloop app, and I don't see any common code that could be promoted to a base class like ApplicationComponent. Could you give some examples of how you use this feature, behavior common to many component classes?

barriehadfield commented 6 years ago

My view is that it is a good pattern that we should document but not be too prescriptive about. It is a very solid idea though and certainly a good one.

sfcgeorge commented 6 years ago

@barriehadfield I'd usually agree with keep it simple out of the box, but as Rails generates ApplicationRecord and ApplicationController is seems better to be consistent.

@explainer A method I added within days to help with accessing routes: https://github.com/ruby-hyperloop/hyper-react/issues/228

sfcgeorge commented 6 years ago

Another use case is with metaprogramming stuff. I'll give an example with controllers.

I wanted to autogenerate tests that every "admin_" prefixed controller included an admin authorization concern. You can loop through descendants of ApplicationController. I had an admin controller extending the RailsAdmin engine that's completely separate and I didn't want to mess with, but since it inherits from RailsAdmin::ApplicationController it's ignored anyway.

Basically having a common namespace you own that's different from what engines use helps with metaprogramming, otherwise everyone inherits from the same Hyperloop::Component and it's harder to differentiate.

It's easy enough to do add ApplicationComponent manually so this isn't an essential feature unless we deem it a beneficial default.