The concept itself reminds me of Rails cells a company I worked with was using. I remember we hated them because of some issues but the idea behind it was sound. We were using cells only for reusable parts. Shared partials on steroids.
It's not that different from components in the frontend frameworks. You isolate a piece of view's template and behavior (how big depends on you) and you declare what you need in input (like props) and output some HTML.
I really like the idea, for the following reasons mentioned in the GitHub issue:
This discourages us from testing our views thoroughly, due to the costly overhead of exercising the routing/controller layer, instead of just the view. It also often leads to partials being tested for each view they are included in, cheapening the benefit of DRYing up our views.
System tests in Rails are sloooow. I would much prefer using an end to end (e2e) testing framework like Cypress instead of writing tests in Rails. If view components can shave time from that, it's not a bad idea per se. Though e2e tests are not the same thing as isolating a piece of view and testing it.
Many common Ruby code coverage tools cannot properly handle coverage of views, making it difficult to audit how thorough our tests are and leading to gaps in our test suite.
I see this "problem" in all Rails codebases. We tend to use lots of logic inside views and it's not easy to understand if it's tested or not, you should do it with system/e2e tests if you don't forget. So if you surface views in Ruby objects, code coverage will tell you instantly if that part of the code is at least stressed once or not
Unlike a method declaration on an object, views do not declare the values they are expected to receive, making it hard to figure out what context is necessary to render them. This often leads to subtle bugs when we reuse a view across different contexts.
This I admit is a pet peeve of mine :D Rails inserts controller instance variables, @article for example, inside views. Which is fine for first level views but a very popular convention is to use instance variables in partial, which down the line makes it difficult to understand where that variale comes from when you're debugging.
Frameworks like Flask force you to explicitly pass the variables used in the template from the controller. Similar to when you give local variables to a Rails partial. That helps to track down where something comes from.
Our views often fail even the most basic standards of code quality we expect out of our Ruby classes: long methods, deep conditional nesting, and mystery guests abound
We adhere to linting tools and quality control but the logic inside views, which is Ruby, is completely ignored by those tools or standards.
One thing I don't like is the possibility of using inline templates, which are basically view helpers
Anyhow, I don't know if this is the perfect or even the right solution, but I support the reasons why they are trying it.
It's weird to me they've decided to insert it in 6.0 which I thought was in feature freeze before the release. This PR is experimental, do they plan to finish the feature before 6.0?
I keep seeing Cyrpus but it is not clicking why I should use it over just writing cucumber tests. Like is it just a plugin that playbacks your steps in the browser so you can exactly see what it's doing. I don't get it.
I keep seeing Cyrpus but it is not clicking why I should use it over just writing cucumber tests.
There's no mistery to it. You write assertions in JavaScript against any website. It doesn't require the runtime or the language of the website the built in. It runs independently as an end to end test. It has a UI, it doesn't use Selenium which is sloooow, it also doesn't require testers to know anything about your code, they can just take the test suite and run it on their computers.
The concept itself reminds me of Rails cells a company I worked with was using. I remember we hated them because of some issues but the idea behind it was sound. We were using cells only for reusable parts. Shared partials on steroids.
It's not that different from components in the frontend frameworks. You isolate a piece of view's template and behavior (how big depends on you) and you declare what you need in input (like props) and output some HTML.
I really like the idea, for the following reasons mentioned in the GitHub issue:
System tests in Rails are sloooow. I would much prefer using an end to end (e2e) testing framework like Cypress instead of writing tests in Rails. If view components can shave time from that, it's not a bad idea per se. Though e2e tests are not the same thing as isolating a piece of view and testing it.
I see this "problem" in all Rails codebases. We tend to use lots of logic inside views and it's not easy to understand if it's tested or not, you should do it with system/e2e tests if you don't forget. So if you surface views in Ruby objects, code coverage will tell you instantly if that part of the code is at least stressed once or not
This I admit is a pet peeve of mine :D Rails inserts controller instance variables,
@articlefor example, inside views. Which is fine for first level views but a very popular convention is to use instance variables in partial, which down the line makes it difficult to understand where that variale comes from when you're debugging.Frameworks like Flask force you to explicitly pass the variables used in the template from the controller. Similar to when you give local variables to a Rails partial. That helps to track down where something comes from.
We adhere to linting tools and quality control but the logic inside views, which is Ruby, is completely ignored by those tools or standards.
One thing I don't like is the possibility of using inline templates, which are basically view helpers
Anyhow, I don't know if this is the perfect or even the right solution, but I support the reasons why they are trying it.
It's weird to me they've decided to insert it in 6.0 which I thought was in feature freeze before the release. This PR is experimental, do they plan to finish the feature before 6.0?
I came across this in recent devchat.tv podcast it is so awesome. They also mention about testing.
I keep seeing Cyrpus but it is not clicking why I should use it over just writing cucumber tests. Like is it just a plugin that playbacks your steps in the browser so you can exactly see what it's doing. I don't get it.
I guess this explains it well
blog.red-badger.com/2017/6/16/cypr...
There's no mistery to it. You write assertions in JavaScript against any website. It doesn't require the runtime or the language of the website the built in. It runs independently as an end to end test. It has a UI, it doesn't use Selenium which is sloooow, it also doesn't require testers to know anything about your code, they can just take the test suite and run it on their computers.
It looks like they merged it into master and not the 6.0 branch so it should be coming in 6.1.
Oooh this makes much more sense, thank you for checking Abraham! I somehow missed the
Rails 6.1.0.alphaAndy wrote in his article.hah me too 🙃