Collecting and documenting Phlex best practices

[hms]

I would love a place to collect Phlex best practices. While I jumped on the Phlex bandwagon early, as I read social media postings and the Phlex discord group postings, it's clear there is so much that I could implement better, didn't understand at the time, or Phlex has made improvements and there are better ways to solve the problem.

At the risk of projecting... examples of issue that that I have struggled with and would love some guidance / discussion, and even possibly a recommended 'The Phlex way' include :

• Where are we putting non-generic components? For example, I have several different ways to display data about a particular business concept in my application. I could try to make one more complete component with arguments to drive the particular view or I could have components specific to that rendering path (controller).

  • Where are we putting the non-reusable components ( views/namespace/controller/_component.rb Vs views/components/namespace/concept/_component.rb)?
  • Either way, we end up with horrid developer ergonomics with long component names

• Examples for how do use Phlex components as turbo_frame response (@joeldrapper did answer this one for me, but I think this is an example of ergonomics and developer patterns where other people might have found / explored ways to streamline)

• Are we as a community trending towards larger components with lots of arguments Vs. sub-classing into variants?

• How are we organizing larger components such as an entire page? A large(ish) view_template block (easier to see at a glance the overall page layout) Vs. lots of little methods to build up the page (1 method, 1 job....)

• Kits

• Is everyone passing around blocks explicitly (def some_method(&) Vs. just free riding on ruby handling that behind the scenes)?

  • Are there times when being explicit Vs. implicit creates / solves problems?

  Am I howling at the moon or....?