A class for each component

[tsujigiri]

In order to be able to deal with more complex logic, each component should have it's own class. It looks to me like MountainView::Component was intended to be the super class to inherit from for this purpose, only that the render_component helper doesn't use it but directly renders the partial and passes along the properties. Are there any plans to change this? I'd be glad to come up with something, as I (together with @matthewcorreia-hitfox) am currently working on incorporating MountainView in our own UI components lib.

[kitop]

@tsujigiri thanks for your comment!
Can you explain a bit more what you have in mind? Maybe an example?
For what I understood, it could be something similar to cells.

MountainView::Component was intended to simplify some logic in the stylesheet, more than each component. But it may make sense to extend it a bit, or use a similar idea to create components.

I really want to hear more about what you have in mind!

[tsujigiri]

I'm pretty much thinking of something similar to Cells. In order to get some more documentation out of it, I could imagine requiring the params each component accepts to be explicitly declared. E.g.:

class Card < MountainView::Component
  property :title
  property :description
  # ...
end

Maybe with an additional boolean parameter for declaring mandatoryness. The styleguide generating code could then iterate over these classes. All properties would appear in the styleguide.

In the YAML file, the example values could also be required to be set. This would then force the developer of a component to also document it. Additionally, having a short description of each property as well as the component itself might be nice. These could also live in the YAML file.

The class part could also be achieved with POROs with a method that would return a Hash of properties to be passed to the render_component helper, though. I can also see MountainView as a pure view layer, not imposing any structure for containing the logic and keeping it as flexible as possible.

You be the judge. :)

[kitop]

@tsujigiri I like the idea initially. We'll have to give it a bit more thought though.
Originally, the MountainView::Component object was extracted as a class to reduce the amount of helpers and code duplication.

You're proposition is really nice but, right now, means a big change to how Mountain View works—but the idea is really nice. We thought a bit about cells when we initially were developing MV, and it's definitively a route we'd like to explore.

Of course, feel free to fork or send a PR :)

Really glad you're using Mountain View. If you can share more info on how and for what, that would be super helpful. You can find our emails in the gemspec if you don't want to make it public.

[kitop]

@tsujigiri would like your input on @tombeynon's contribution on #26