Rendering a component with both js.erb and html.erb

[mickenorlen]

Hi and thanks for this gem!

I'm wondering if it is possible to render a component that uses both js.erb and html.erb. If possible I would also like to be able to render this component from both js.erb and html.erb files. I think this could be solved with more html markup to communicate with sidecar js assets. But i think there are often benefits of working directly in js.erb syntax so that is what this question is about.

Consider this example where a toolbar button is added either directly from a html.erb with a <script> tag or inserted to the DOM with insertAdjacentHTML from js.erb.

From html.erb with <script>

# some_parent_file.html.erb
<%= render ToolbarItemComponent.new %>

____________________________________
# In this case it would go to a html.erb
# toolbar_item_component.html.erb

<%= TOOLBAR_ITEM_HTML %> 

<script>
  <%= TOOLBAR_ITEM_JS %>
</script>

From js.erb with insertAdjecentHTML

# some_parent_file.js.erb
<%= render ToolbarItemComponent.new %>

____________________________________
# Then it would look for a js.erb, but since multiple partials per component isn't 
# allowed this kind of structure wouldn't really work right?  
# toolbar_item_component.js.erb

document.querySelector('#toolbar).insertAdjacentHTML('beforeend', "<%= TOOLBAR_ITEM_HTML %>")

# QUESTION HERE. 

# Where can I put the TOOLBAR_ITEM_HTML that i'm referencing above?
# How can i avoid the battle with html in quoted strings?
# Its probably a noob question but how would i import another partial to this component?

<%= TOOLBAR_ITEM_JS %>

Possible solution

I was thinking about splitting the component in two somehow. Could this be an option? How would i write the js method then to simulate the html rendering logic? And in what file/method would be a good place to put that js code (i dont want to write it in a quoted string)? How to include for example components/_toolbar_item_component.js.erb?

<% toolbar_item = ToolbarItemComponent.new %>

# get html
<%= render toolbar_item %>

# get js
<%= render toolbar_item.js %>

I'm very open to any kind of suggestions on how to structure and render this component.

Thank you for your time!

[joelhawksley]

@mickenorlen thanks for stopping by! Let me see if I can be of help.

Right now, ViewComponent is more or less hardcoded to output HTML:

https://github.com/github/view_component/blob/7b8ae832d56f59fccfb8b95b6daae8ad4164abd0/lib/view_component/base.rb#L233-L239

If we wanted to support rendering Javascript (which is something ERB is definitely used for!), we'd need to first look into supporting .js.erb templates. If you'd like to go this route, I'd be interested in seeing a PR 😄

In your specific example, it looks as though you would need to have HTML shared in between the js.erb template and the html.erb template, which would likely necessitate a partial or another component.

That being said, I think you could keep the Javascript wrapping of the component as a partial, and then render the component inside that partial:

# toolbar_item_partial.js.erb

document.querySelector('#toolbar).insertAdjacentHTML('beforeend', "<%= ToolbarItemComponent.new %>")
...

I hope I understood your question. Thanks again ❤️

[mickenorlen]

I see! Yeah i was trying to look into the source a bit and found that type method also. But then when i tried to render a component with a .js.erb template (from a js.erb file) it still works! So i don't think it's very far away to being fully supported :P

But what I think could be useful (apart from fully supported js.erb rendering) is:

1. A method that renders partials relative to the component (be it js.erb or html.erb) - with instance variables etc available as for the main template.

2. Maybe even support multiple templates from scratch so you can specify in render which format you want?

So then I could inject html to js or vice versa, split larger components in different parts if needed,
and render a js adapted component version with something like:

<%= render ToolbarItemComponent.new.js %> 

<%# Or if supporting multiple templates from scratch %>
<%= render ToolbarItemComponent.new, format: 'js.erb' %>

toolbar_item_component.rb

class ToolbarItemComponent < ApplicationComponent
  helper_method :js, :html

  def js
    render_template_partial('toolbar_item_component.js.erb')
  end

  def html
    # Maybe even a method like this to distinguish between partials and main templates?
    render_template(format: 'html.erb')
  end
end

_toolbar_item_component.js.erb or even just toolbar_item_component.js.erb if multiple main templates supported

const toolbar = document.querySelector('<%= @toolbar %>');

toolbar.insertAdjacentHTML('beforeend', "<%= html %>")

...

Right now I feel lacking in both time and confidence to implement this. But maybe I could give it a try in a couple of weeks :P Again thank you for taking the time! <3

[joelhawksley]

@mickenorlen thanks for the detailed explanation!

Right now I feel lacking in both time and confidence to implement this.

No worries! It would be helpful to have you provide a PR that adds some example components and test cased for what you’re trying to accomplish. Doing so will help us figure out what APIs make sense here ❤️

[mickenorlen]

Alright. I'll try to look into it later on. May peace and health be bestowed on you until then! :D

[mickenorlen]

My current solution to:

1. A method that renders partials relative to the component (be it js.erb or html.erb) - with instance variables etc available as for the main template.

class ApplicationComponent < ViewComponent::Base

  def render_template(name, is_partial = true)
    auto_fill_exts = ['html.erb', 'js.erb']

    name = "_#{name}" if is_partial

    call_file = caller[0][/[^:]+/]
    parent_dir = File.dirname(call_file)
    file_path = "#{parent_dir}/#{name}"

    if File.file?(file_path)
      final_path = file_path
    else
      auto_fill_exts.each do |ext|
        new_path = "#{file_path}.#{ext}"

        if File.file?(new_path)
          final_path = new_path
          break
        end
      end
    end

    raise "#{name} not found in #{parent_dir}, tried exts #{auto_fill_exts}" if !final_path

    file = File.open(final_path).read
    template = ERB.new(file)
    template.result(self.binding).html_safe
  end
end

Regarding

2. Maybe even support multiple templates from scratch so you can specify in render which format you want?

I started experimenting with this kind of structure (as discussed here #331)

app/components
├── alert
...
└── form
    ├── text_field_component  
        ├── index.css
        ├── index.html.erb
        ├── index.rb
        └── index.js

         # HERE is an example of alternative entrypoints for text_field_component!
        ├── js.rb 
        ├── js.js.erb
        ├── variation2.erb # And some other variation
        ├── variation2.html.erb

Which gives me multiple entrypoints through

Form::TextFieldComponent::Index # Main template
Form::TextFieldComponent::Js # Js template

[jonspalmer]

I still not clear on the advantages of the later. What code goes in form/form_component/js.rb? Why is it preferred to have

<%= render Form::TextFieldComponent::Js.new .... %>

vs

<%= render Form::TextFieldComponent.new(format: :js) .... %>

[mickenorlen]

I think we could support both options. Because

• ::JS might be sufficiently different to already prefer it's own component class. You might not want to bloat the standard html component with logic for your js rendering.

• ::JS could be something other than another language format. Imagine working with something a bit more complex like some kind of layout components with different types of characters and fields. Then you would have 3 options:

1. Everything in the same component, with conditionals about which template to show, which input variables are required depending on type, what is required for render? etc - basically everything jammed together.

LayoutComponent.new(type: 'standard')

2. Everything in different components.

Layout::StandardComponent
Layout::ArticleComponent

3. Variants of the same component

LayoutComponent::Standard 
LayoutComponent::Article

I think there will be situations where 3 can make a lot of sense. Imagine that they share some of the same assets, core styling and js functionality etc. But that they are still sufficiently many or different to bloat the main component file with conditions. Would it really make sense to separate them into different components? Would you then also have to put common "base" assets in the namespace directory?

app/components
└── layout
     # General layout base and assets
    ├── layout_component.rb
    ├── layout.scss
    ├── layout.js

    └── standard_component  
        ├── standard_component.rb
         # Variant assets
        ├── standard_component.js
        ├── standard_component.scss

    └── article_component  
        ├── article_component.rb
         # Variant assets
        ├── article_component.js
        ├── article_component.scss

Also. File searching something like standard_component or article_component would clash with any other variant with the same name in another namespace eg, Image::ArticleComponent for an image that suits an article.

Basically I feel that this kind of structure (possibly with shorthand namespace delegation as the discussion continues #331) would empower users with all the options to chose what suits their needs/components and view frameworks - from the very simple single html file component, to the complex and unexpected use cases - while still following no surprise conventions. And it could be adapted on a per component basis.

Update

Found another reason when variants can be useful. If you have a multi step process type of component. For example a button - that makes a request - that then renders another step.

[jonspalmer]

Sure I think of this a little bit like how Controllers work today in Rails. You can have the same controller return json and html but there will be situations where you want PersonController and API::PersonController with various differences (often authentication etc.)

That said modulo the issues around directories/namespaces I think everything you describe works today other supporting different formats in a single component. I think we focus this issue on that right?

[mickenorlen]

Sounds good. Unless you want to make render_template part of the core somehow to help people split code into partials? I'm fine with my own version for now so I don't mind.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.