search

PhlexUI / phlex_ui

Ruby gem for Phlex UI Components
https://phlexui.com/
MIT License
114 stars 11 forks source link

Remove ActiveSupport methods from `PhlexUI::Select::Builder` #44

Open oneiros opened 2 months ago

oneiros commented 2 months ago

As described in #43 I tried to get rid of ActiveSupport. As it turns out, this is not so simple.

PhlexUI::Select::Builder makes use of the String extensions classify, contantize and underscore. These methods are not trivial to reimplement. The AS versions have been refined over a long time and cover many edge cases.

If we want to keep PhlexUI::Select::Builders functionality mostly as-is, that would leave us with the following options imo:

  1. Keep ActiveSupport as a dependency and embrace it (many non-rails ruby projects do).
  2. Research AS alternatives that are less invasive (I vaguely remember there being a couple of projects with that goal, but cannot remember any names from the top of my head.)
  3. Re-implement the aforementioned methods.

But I think there are other, better ways, if we consider what PhlexUI::Select::Builder actually does. I think it is a kind of outlier because I am pretty sure it is the only component / builder that is built with usage in rails apps explicitly in mind. The API and the fact that it constructs form input name attributes that follow rails conventions makes me think it was created for usage in rails forms first and foremost. But not even PhlexUI::Form::Builder is tailored that way (instead making the name attribute of inputs a mandatory parameter).

So I believe another, possibly better set of options would be to either:

  1. Remove PhlexUI::Select::Builder altogether. I believe it is only useful for a narrow use case anyway and using the "deconstructed" version is not that hard.
  2. Create a second gem, phlex_ui_rails and move PhlexUI::Select::Builder there. This might be a good first step for providing rails specific functionality. In the long run, at least a form builder for rails apps would be brilliant I think, so this might make sense.
  3. Refactor the API of PhlexUI::Select::Builder to work without magic string transformations. I do not think it would have to change much, but there are different approaches to this.

(Personally, I tend towards 4, because something about the API of PhlexUI::Select::Builder feels off to me, but I cannot point my finger at what exactly it is. Thus I am not sure I could produce a better one.)

What do you think?

iseth commented 1 month ago

Hey @oneiros sorry I've been afk for the past couple weeks but great write up and love the direction you are taking this.

Rails does account for a good amount of ruby apps and keeping rails support is very important. That being said I still agree it would be nice to have the AS functionality extracted out into another gem like phlex does to allow phlex_ui to be used anywhere even without rails.

So I fully embrace going with option 5.

I can start a new project and we can test abstracting out the builder functions into that gem and also update the documentation site to reflect that.

oneiros commented 1 week ago

I updated my PR (#43) and removed Select::Builder. Feel free to reintroduce it in a seperate gem at a later point.

(FWIW, I would have loved to have helped with that, but I am starting a new job next monday and will probably not have time for that in the foreseeable future :frowning_face:).

iseth commented 1 week ago

@oneiros Thanks for the suggestions and for the help.