Maintenance Status

[zacheryph]

Hi, I wanted to ask about the status of this project? It is something I am interested in using but wanted to check on whether PRs would be looked at, reviewed, merged, released? If so, should I open tickets before making too many changes? (If I don't hear anything I can plan on releasing any changes I make under a different name.)

I wasn't sure if there were any things you could tell me you know/remember off hand (though I can figure out myself as I dig in more.) Have you ran any benchmarks (i do note the ticket on partial collection performance)? Are there any known issues / limitations not noted in the Readme or tickets? Anything (or nothing) is fine.

I do like the looks of this, and wish I had found this project a long time ago. With Turbo (and a little component library) I think it could be a very nice alternative to React.

[patbenatar]

@zacheryph Hey! We use this project heavily at my work so it's actively maintained and kept up-to-date with latest Rails versions.

I'd welcome your contributions :) -- opening issues ahead of time is a good idea and I'll be happy to discuss your ideas on those issues. The project is currently well-tested and I'd like to keep it that way, so please write tests for any new functionality and maintain the existing suite as you make changes.

Performance-wise I haven't done any exhaustive benchmarking but we get very good response times in our relatively high-trafficked production Rails app. There's a rudimentary scaffold for performance testing in the spec dummy app here. Every once in a while I tinker with an approach that eliminates the dependency on ActionView and thus gets pretty substantial performance gains in this branch.

As far as I know, all of the known issues are captured in the Issues list.

Looking forward to collaborating!

[zacheryph]

@patbenatar Love to hear that.

Regarding moving away from ActionView, it might be good to look at depending on it less or.... more.

In my initial messing around I updated everything, and found in rails master they completely removed HTML_VOID_ELEMENTS

[patbenatar]

The tight coupling with ActionView and Rails is a double-sided sword. Some pro/cons that come to mind:

Pros:

• It makes the integration with Rails seamless and it feels familiar to Rails devs, ie you can access the view context and code like you're in a regular Rails template (helpers, ivars, etc)
• We leverage Rails features like template loading, caching, dependency tracking for cache busting, etc

Cons:

• Depending on Rails internals means every Rails update requires work on our end to maintain compatibility
• ActionView brings a lot with it and can be slow (relatively speaking - it's actually very fast all things considered)

My idea was to introduce an optional Rbexy::FastComponent superclass that has no dependency on ActionView and allow users to opt-in to speed at the cost of losing the niceties of ActionView. So we'd have both Rbexy::Component with its ActionView coupling and Rbexy::FastComponent as a more bare-bones option. Ideally they could be used together in a component tree.