Namespacing issues

[Steven Schmid]

Hey guys

I just submitted the PR #116 but I stumbled upon a problem with it: I assumed (wrongly) that a component generated via rails g component 'hello/world' would create the main view as components/hello/world/_world.html.slim. Instead, it creates components/hello/world/_hello_world.html.slim

is there a rationale behind this? And why is the generated ruby component not properly namespaced as well?
Expected: module Hello::WorldComponent
Actual: module HelloWorldComponent

Is this an oversight or deliberate behavior? Because if I execute rails g component 'foo/bar' and rails g component 'foo_bar' I end up with two modules with the same name.

[Hans Lemuet]

Hi @stevschmid thanks for opening this issue and for your PR :)

The idea behind the components/hello/world/_hello_world.html.slim naming is to keep the filename explicit enough about the current component namespace.

If you have several components named item for instance, each in their own namespace, it quickly becomes a mess in your editor when you open several of them in tabs, because they would all be named _item.html.slim

That's why we chose to keep the whole namespace in the component view filename.

About the Ruby module name: we sticked with HelloWorldComponent because we did not want to deal with the added complexity of relying on Ruby namespaces (you can create collisions with existing classes pretty easily on large projects).

Does this answer your questions?

[Steven Schmid]

Thanks @Spone for your quick reply, really appreciate it!

I don't think the editor behavior when dealing with a lot of files with the same name should dictate such a fundamental design choice. I'm pretty sure there are editors and plugins out there which would expand the display to include the parent directory if two files with the same name are open.

Proper namespacing comes with the price of added complexity, I agree. But the current namespacing implementation is

a) flawed (since it leads to modules with the same name). See my example above with rails g component 'foo/bar' and rails g component 'foo_bar', which results in the same module FooBarComponent.

b) inconsistent with Rails (and since this is a Rails gem, you anticipate the same generate behavior as Rails). rails g controller 'foo/bar' creates a Foo::BarController, rails g controller 'foo_bar' creates a FooBarController.

I understand that changing the generation behavior is a scary thought, but I believe it's the correct way.

[Hans Lemuet]

I agree those are valid issues to consider. We'll discuss it and let you know (probably second half of September, I'm going to be on vacation until then).

[Steven Schmid]

No worries. Thanks for getting back to me so quickly. Enjoy your vacation!

[Hans Lemuet]

Hi @stevschmid,

we're considering fixing the issue. Let's discuss how this could work:

• we deprecate the current naming scheme components/hello/world/_hello_world.html.slim in an upcoming version of the gem, and encourage users to switch to components/hello/world/_world.html.slim
• ideally, we provide a script that can migrate the naming automatically by:
  • replacing the files names (partial, Ruby module, CSS, JS, stimulus controller)
  • renaming the Ruby module
• in the next major version, we only allow the new naming scheme

Do you see anything else?

[Steven Schmid]

Hey @Spone

Thanks for getting back to me. Sounds great!