Converting views to Phlex

[joeldrapper]

Hey @sudara, I’m thinking about forking alonetone and converting all of the views to Phlex, with documentation in Lookbook (lookbook demo), as a way to demo the Phlex framework in the real world.

Would you potentially be interested in me contributing this work upstream?

[sudara]

Hey Joel!

Phlex looks interesting! Something about it (terseness?) reminds me of haml a bit (obviously a different beast)!

I'd have a few maintainability concerns re: upstreaming. Maint is a big deal for us, alonetone has been in production for 15 years (rails 2.0!)

• I'm unclear if the benefits outweigh the cost of moving away from default rails / html. We do visual regression testing to catch anything that slips out of place. I'm personally not big on testing views in isolation. I am big on performance, so that part seems attractive, but I'm not sure how beneficial this could be, for the most part we tend to suffer from the same n+1/db query issues that most rails apps have to mitigate.
• Our main frontend contributor writes html/css, this would require them to work in an unfamiliar context
• Our views get pretty nested and complex and have a fair amount of debt. Clean up and attention on view nesting itself would be of huge value to us, especially if would mean making them more cachable. Are there examples of view caching in Phlex? (such as russian doll style)
• I wouldn't want to upstream a partial implementation and sort of get stuck in the middle. A full translation seems like it could be pretty time intensive (thinking about all the details in "the last 10-20%" of the work), do you think alonetone would be a good fit size-wise?

[joeldrapper]

Hey @sudara, sorry I didn't get back to you on this earlier.

To answer a couple of your points: Phlex has an advantage when it comes to IO-bound performance because you can stream up to the point where the view depends on that IO. For example, you can start an asynchronous database query in the controller and render the view at the same time. When the view needs the results of the query, if it hasn't loaded yet, it streams what it has up to that point before waiting.

Re: caching. Phlex doesn't need view caching because it's already fast.

I totally get your points about the main front-end contributor writing html/css and about size of the project. Based on this, it might not be right for now.

[sudara]

Hey Joel! No worries!

That's really cool about the view streaming. Interesting!

Phlex doesn't need view caching because it's already fast.

I might have been unclear here, what I meant re: view caching was fragment caching and in particular russian doll caching.

The reason for fragment/russian doll caching isn't because view rendering itself is slow, but to avoid hitting the database when rendering views as much as possible. The idea is to generate html for (lets say) a user's comment only once, as it might make a couple db requests, is used on multiple pages, etc. alonetone does take advantage of nested caching in views quite a bit, and I would like to increase that if possible, as we are hitting some pain points there.

[joeldrapper]

My understanding was that Russian doll caching was primarily to improve the performance of the view layer because most database queries are adequately fast enough if you don't have n+1s.

Phlex doesn't have any view-layer caching, but you can of course use Rails’ low-level caching to cache database queries. This should mean much smaller cache sizes, and caches of the same resource could be shared, even when rendered in different views.