komposable / komponent

An opinionated way of organizing front-end code in Ruby on Rails, based on components

Home Page:http://komponent.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

component helper using relative paths

ribanez7 opened this issue · comments

Hi, first of all congratulations for the job done, I really enjoy working with the gem. I was wondering if are there any plans to incorporate the possibility of rendering components using a relative path.
I know that's not railish enough, but I think its kind of a elementary feature for frontend frameworks, most of all, due to rehusability.

A case example would be a component which needs two children components. There should not be necessary to write the full path of the component, since both child components have no sense alone.

A solution, in order to avoid simulating the javascript imports (like './component_name'), would be to start the lookup of a component from the current directory. So in this example:

one_component/
  _one_component.html.erb
  other_component/
    _other_component.html.erb
other_component/
  _other_component.html.erb

Calling

component('other_component')

from _one_component.html.erb would consider first the partial under one_component/other_component/_other_component.html.erb

Could you please let me know if that makes sense for you, or if you think that it is not a necessary feature? In any case, I could also work on it.

Thanks

Hi @ribanez7 thanks for the issue!

I think it really depends how you use the component nesting feature. In some projects, I use it to split a complex component into smaller subcomponents. In this case your idea makes sense.

But on other projects, I use nesting as a way to organize the components by namespace, such as admin or form, and subcomponents are not necessarily rendered by a parent component. In that case, this feature can be confusing: if I see = component "button" I would have to check the path of the file to know if the rendered component is admin/button, form/button or button.

So I'm not sure it's a clear improvement. I'd rather make sure it's always easy to know which component in rendered.

But maybe you have some specific use cases in mind?

Hello @ribanez7 ,

Rails doesn't permit to do that kind of nesting with relative paths for their partials (rails/rails#1143), as we rely on Rails for rendering our components, I don't think we can introduce this feature without make the same abstraction than cells do.

In your example:

one_component/
  _one_component.html.erb
  other_component/
    _other_component.html.erb
other_component/
  _other_component.html.erb

You have access toc ('other_component') andc ('one_component / other_component')in controllers / views or in any others components. That make pretty clear which component you want to render.

Absolute paths are not that bad, like a lot of people doing components limit depth to 3 levels. Relative paths don't make code / organization clearer, rather the opposite, so that's not a feature we should implement in near future.

But you can explain your use cases, maybe I don't get it the benefits you see, I'm not closed to discuss about it.

I have been thinking on your comments and you convinced me :-), also I have encountered cases where the relative lookup is a problem. Yes, from my point of view, there are reasons enough to preserve the absolute path approach.
Let me close the issue.
Thanks!