Pages and Components

[stephannv]

From official docs:

In Phlex, layouts, pages and components (or “partials”) are the same thing.

Yeah, but what do you think about suggest organizing the phlex objects into 2 folders (pages and components)?

This can be done inside app/views folder:

• app/views/components
• app/views/pages

Or using app folder:

• app/components
• app/pages

Pages represents the application views, the html response from controllers, the PostsController#index renders pages/posts/index.rb. Pages usually represents a route and are rarely reused but can take all other advantages from Phlex framework. We could create a ApplicationPage to setup some shared behavior (eg. metatags).
Components are what makes up the different parts of your page and can be reused and imported into your pages, layouts and even other components.
They are the same, but they are different.
It is already possible to organize things the way I wrote, but what do you think of this as a good practice recommendation in the docs.

[joeldrapper]

In a Rails app, I personally like to organise views based on the resources they represent. For example, if I have an Articles resource, I’d have Articles::Index and Articles::Show (the pages) right next to Articles::Article, Articles::List, Articles::Form, Articles::Table, etc.

That said, the way you organise your views is a personal choice. You can use the same generators with Pages:: or Components:: prefixes, e.g. bin/rails g phlex:page Pages::Articles::Index and bin/rails g phlex:view Components::Articles::Table work just fine.

[evenreven]

Speaking only for myself, I actually think it's liberating to think of Phlex components as not tied to controllers at all, and I go further and consider Phlex page views templates and not controller actions either. Sometimes page templates can be very similar across different models. In my case news_items#show and research_projects#show would look more or less identical and could really be one Phlex view (page) (app/views/templates/regular_page.rb or whatever) with different content passed into the Phlex view from the controller. This depends on how similar-looking the views are meant to be from a design standpoint. (In my project ResearchProject would primarily be its own model because it also belongs_to Employee and get its content from a different source (an API).) In a lot of cases I would just use the controller action structure because it's easy to understand, but it's nice to know I don't have to.

[stephannv]

Yeah, makes sense.

[oneiros]

Sorry for piggybacking off this discussion, but I would like to add a small point that is kind of bothering me:

I agree to most of what was written above, but if I see this correctly, current defaults in phlex-rails differ from this is in one important way: Currently it will wrap everything, pages and components, in the View namespace (e.g. Views::Articles::Index instead of Articles::Index).

Do not get me wrong, I am totally in favor of using modules as namespaces in ruby as much as possible. And I sometimes regret that rails did not do that properly from day one. But since it did not, I believe rails developers have come to expect that classes in a direct subfolder of /app include top-level constants. The current defaults break this expectation.

So I think I would prefer that (as a default) /app/views/articles/index.rb defines a class Articles::Index.

As a side-effect, this would mean that we could replace

config.autoload_paths << "#{root}/app"

in /config/application.rb with

config.autoload_paths << "#{root}/app/views"

which is a lot narrower.

The former worries me a bit because of its broad nature. I have not come across an actual conflict yet, but at the very least it introduces some ambiguity (does /app/models/user.rb define User or Models::User?). And I fear this could lead to subtle (and maybe not so subtle) problems in larger code bases.

[joelmoss]

I'm kind of erring on the side of appending View to classes, in the same way that almost everything else in Rails is, including controllers and helpers. (models are the exception here)

This completely removes conflicts and make it very clear what a class is. It also has the added benefit of being able to differentiate between components and views...

/app/views/articles/index_view.rb => Articles::IndexView
/app/components/articles/comment_component.rb => Articles::CommentComponent

This is currently my preferred approach, as it feels much more Rails-like.

[stephannv]

I'm trying the following approach in my side project (https://github.com/stephannv/stefin):

app/
  views/
    accounts/
      components/
        card.rb
      pages/
        new.rb

So I have Accounts::Components::Card and Accounts::Pages::New classes.

[joeldrapper]

It's great that you can organise views however you want — and maybe we should introduce some configuration for the phlex-rails generators. However, I should explain some of the reasoning behind the defaults.

Namespacing views under a Views module means there is no chance of a collision with another object such as a model. It's common to name a view after the object (or model) it represents, so collisions are likely without a namespace.

Rails has traditionally put the type of object at the end of the name for everything apart from models — e.g. ArticlesController, PublishArticleJob, etc.

I don’t think this is a great pattern. I would change Rails to namespace Controllers and Jobs if I could, so you’d have Controllers::Articles and Jobs::Articles::Publish. This would fit with Zeitwerk conventions making it easier to map a constant to a file name in your head and would help with auto-completion, etc. too.

I recognise namespacing goes against the established pattern, but I think there's quite a big difference: controllers rarely reference other controllers and jobs seldom reference other jobs, but views reference different views all the time.

I think this is where Ruby’s relative constant lookup can be really useful. If I’m in the Views::Articles lexical scope, I can just render List to render the Views::Articles::List view. That terseness may not be for everyone, and if you're always using the fully qualified name, Views::Articles::List, you may as well reference Articles::ListView instead. At the very least, I think the Views:: part should be omitted when referencing a view from a view but that’s a matter of style which is a matter of taste and opinion.