Rename option-related variables to reflect vanilla Rails conventions
gazayas opened this issue · comments
After some discussion in #587, it has become clear that we should use our options like this:
options
: Options for buttons/select fields/etc. For example,["one", "two", "three"]
.html_options
: The same as the Rails helpers in that we set the class attribute, etc.other_options
: Bullet Train specific options. For examplehelp
,hide_label
, andrequire
.
Read this comment for more details.
@jagthedrummer suggested that we use either bt_options
or fp_options
instead of other_options
. I think this is a good idea, and that it will be clearer for everyone to understand.
#587
I think we should figure this out before #587, because I foresee this being a pretty big PR and it might be better organize things mentally before merging the disable
logic from there.
I made another discovery that has an affect on how we should name our variables.
Our fields (_text_field.html.erb
, _email_field.html.erb
, etc.) are eventually filtered into bullet_train-themes-light/app/views/themes/light/fields/_field.html.erb
. So, say for a text_field
, we eventually invoke the Rails form helper here with form.send
:
Looking through the Rails form helpers, most of them have the following arguments, so I can see why we use options
in _field.html.erb
:
def text_field(object_name, method, options = {})
...
end
In options
here, we were putting the html class
in there along with other things. So, @jagthedrummer, you were right in your comment here in that html_options
is accomplishing the same thing with options
. The problem is...
partial.field?
This isn't the case when partial.field?
is true
, but we're still using <%= render 'shared/fields/field' ... %>
for EVERYTHING, forcing us to conflate options
and html_options
although they should be separated depending on what partial we call.
Say we super scaffold a text field and a super select field.
> bin/super-scaffold crud Project Team title:string types:super_select
Here are the attributes in _show.html.erb
:
<% with_attribute_settings object: @project, strategy: :label do %>
<%= render 'shared/attributes/text', attribute: :title %>
<%= render 'shared/attributes/super_select', attribute: :types %>
<%# 🚅 super scaffolding will insert new fields above this line. %>
<% end %>
As you can see, they're just the same render
calls. However, if partial.field?
is true
we get a different invocation from text_field
which doesn't necessarily use (object_name, method, options = {})
for its arguments. For the super select field, it yields true
for partial.field?
because we pass a block to the render call:
This is where html_options
comes in.
As you can see here, it's using the Rails select form options helper which has a different set of arguments:
def select(object, method, choices = nil, options = {}, html_options = {}, &block)
...
end
Conclusion
We don't have a meaningful way of separating options
and html_options
depending on the partial because we just put everything in a render
call, even though the arguments are different from helper to helper.
I'm still processing how to handle this one. I at least hope we can add comments to the code base to make it easier to understand what's going on.
I also still want to change other_options
to bt_options
.
I'm also seeing this in the field partial docs.
Individual field partials might have additional options available based on the underlying Rails form field helper. Links to the documentation for individual form field partials are listed at the end of this page.
We could potentially update this to say:
"Individual field partials might have additional options or different uses for options
and html_options
based on the underlying Rails form field helper."