Removed required keyword arguments for Ruby 2.0 compatibility#392
Removed required keyword arguments for Ruby 2.0 compatibility#392zimmru wants to merge 9 commits intoshakacode:masterfrom
Conversation
|
@zimmru Any reason you can't move to Ruby 2.1? |
|
Seems like an easy win for extra compatibility though |
|
For those of us that can't use rvm (no internet access, rpm requirements, etc.) or already have other gems that force a ruby version, changing ruby versions is a really big deal. In my case 2.1 is a deal breaker. Ideally this gem should match the ruby requirements of rails 4, which is "Ruby 2.0 preferred; 1.9.3+ required". With such a small number of rails projects using react, it seems wise to me to try to be as inclusive as possible to make it more mainstream. I agree with @robwise, this seems like an easy win for the extra compatibility. |
|
I agree, it's a good change to make easier adoption. However, I would want to see some sort of linter check added as part of this PR which would fail if any incompatible syntax is added, if that's possible. Otherwise other incompatible stuff will just get added in the future. |
|
Sounds good -- Once this passes CI, I'll review and merge. |
|
Reviewed 2 of 2 files at r1. Comments from Reviewable |
|
@zimmru I can't merge this until it passes CI. |
|
There were a bunch of recent commits that use Ruby 2.1 features, so it's no longer the handful of lines that are different. Probably not worth trying to maintain at this point. |
|
@zimmru Are you able to update to Ruby 2.1? Are there any strong reasons that people want to use an advanced tool like React on Rails, with an old version of Ruby? |
|
@justin808 It's, of course, easy to update my dev machine to Ruby 2.1. The issue is at work, where our servers have Ruby 2.0 on them. Updating them is a bit of a pain. |
|
@zimmru Yep. I feel your pain, but that's why Containers (e.g. Docker) and PaaS are all the rage and the direction of the future - persistent servers are difficult to move forward without effort and risk - even if you use tools like Chef and Ansible to automatically and declaratively update them. But, it's a good direction, for good reasons... |
|
@thewoolleyman It is important to note that PaaS is not always an option for those that must host their own stuff. If you are required to deploy on other people's hardware this becomes even more problematic as many times you will not have access to the internet. For complex installations, containers aren't always a feasible solution. |
|
If we get several people that want this, and the PR is good, I'll merge. |
|
@justin808 I still think we should require a linter to fail in CI if newer syntax is used to consider this mergeable. Otherwise, we'll just have a continuous stream of issues like this as people inadvertently use newer syntax on master and in pull requests. |
|
I'm closing. If several people want Ruby 2.0, please comment. |
|
I'm using JRuby 1.7 and am unable to upgrade to JRuby 9000 (company won't allow it currently). It would be great if this issue could be re-opened |
|
@austinfox Your use case sounds valid. If you can make a PR that fixes this, I'll merge it. Otherwise, my team at ShakaCode can contract with your firm and get it done. |
…452) To prepare for HTTP/2 support, we need to switch to a new HTTP client library on the Ruby side. Extracted from #392. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes - **New Features** - Added support for streaming server rendering, enhancing performance for server-rendered React components. - Introduced functionality for replaying console logs during server rendering for improved debugging. - Enhanced error handling for server rendering with new configuration options. - Improved handling of multipart and form data for file uploads. - **Bug Fixes** - Improved handling of HTTP request errors and response status checks. - **Documentation** - Updated configuration documentation for clarity on timeout settings. - **Chores** - Updated dependencies and removed support for outdated versions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alexey Romanov <[email protected]>
## Summary - **New Features** - Introduced support for HTTP/2, enhancing web performance and reducing latency. - Added a new script for generating SSL certificates for local development. - **Bug Fixes** - Updated response status checks to use integer values for better accuracy in error handling. - **Chores** - Enhanced `.gitignore` to exclude self-signed certificates from version control. - Updated project dependencies to remove outdated libraries and include HTTPX for improved performance. - **Documentation** - Revised `CHANGELOG.md` to reflect new features and deprecated technologies. ## Expectation When communicating between a Ruby server and a Node.js server via HTTP/2, the speed difference compared to HTTP/1.1 largely depends on the context and nature of the communication. 1. **On Localhost:** - **Same Speed or Slightly Faster:** Since the servers are on the same machine (localhost), there is minimal network latency. The overhead of HTTP/2 multiplexing, header compression, and other optimizations might not make a huge difference because the communication happens locally, and the network itself isn't the bottleneck. However, HTTP/2 could be slightly faster due to its ability to send multiple requests concurrently over a single connection. But the difference will likely be marginal. 2. **Between Different Servers (Over the Network):** - **Likely Faster with HTTP/2:** When communicating with a different server over a network (not localhost), HTTP/2's advantages become more pronounced. These advantages include: - **Multiplexing:** Multiple requests/responses can be in flight simultaneously over the same TCP connection without head-of-line blocking, which reduces latency, especially in high-latency networks. - **Header Compression:** HTTP/2 compresses headers, reducing the size of requests and responses, which can improve speed, especially when there are many repetitive headers (e.g., cookies). - **Reduced Connection Overhead:** Since HTTP/2 uses fewer connections due to multiplexing, it reduces the overhead of setting up and tearing down connections, which can lead to faster communication, especially in environments with higher latency. ### Summary: - **On localhost:** The difference in speed between HTTP/2 and HTTP/1.1 will likely be negligible, though HTTP/2 might be marginally faster due to multiplexing. - **Over the network:** HTTP/2 will generally be faster due to multiplexing, header compression, and reduced connection overhead, especially in scenarios with higher latency or when multiple requests are being made concurrently. Closes #379. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes - **New Features** - Introduced streaming server rendering support for improved performance and progressive page loading. - Added replay functionality for console logs during server rendering to aid debugging. - Enhanced error handling during server rendering with new configuration options. - Integrated support for HTTP/2 in the node-renderer for better performance. - **Bug Fixes** - Improved error reporting and handling for HTTP requests. - Updated multiple JavaScript dependencies for better stability. - **Documentation** - Updated `CHANGELOG.md` to reflect new features and changes. - **Tests** - Modified tests to accommodate new HTTP/2 request handling and improved error management. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alexey Romanov <[email protected]>
…452) To prepare for HTTP/2 support, we need to switch to a new HTTP client library on the Ruby side. Extracted from #392. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes - **New Features** - Added support for streaming server rendering, enhancing performance for server-rendered React components. - Introduced functionality for replaying console logs during server rendering for improved debugging. - Enhanced error handling for server rendering with new configuration options. - Improved handling of multipart and form data for file uploads. - **Bug Fixes** - Improved handling of HTTP request errors and response status checks. - **Documentation** - Updated configuration documentation for clarity on timeout settings. - **Chores** - Updated dependencies and removed support for outdated versions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alexey Romanov <[email protected]>
## Summary - **New Features** - Introduced support for HTTP/2, enhancing web performance and reducing latency. - Added a new script for generating SSL certificates for local development. - **Bug Fixes** - Updated response status checks to use integer values for better accuracy in error handling. - **Chores** - Enhanced `.gitignore` to exclude self-signed certificates from version control. - Updated project dependencies to remove outdated libraries and include HTTPX for improved performance. - **Documentation** - Revised `CHANGELOG.md` to reflect new features and deprecated technologies. ## Expectation When communicating between a Ruby server and a Node.js server via HTTP/2, the speed difference compared to HTTP/1.1 largely depends on the context and nature of the communication. 1. **On Localhost:** - **Same Speed or Slightly Faster:** Since the servers are on the same machine (localhost), there is minimal network latency. The overhead of HTTP/2 multiplexing, header compression, and other optimizations might not make a huge difference because the communication happens locally, and the network itself isn't the bottleneck. However, HTTP/2 could be slightly faster due to its ability to send multiple requests concurrently over a single connection. But the difference will likely be marginal. 2. **Between Different Servers (Over the Network):** - **Likely Faster with HTTP/2:** When communicating with a different server over a network (not localhost), HTTP/2's advantages become more pronounced. These advantages include: - **Multiplexing:** Multiple requests/responses can be in flight simultaneously over the same TCP connection without head-of-line blocking, which reduces latency, especially in high-latency networks. - **Header Compression:** HTTP/2 compresses headers, reducing the size of requests and responses, which can improve speed, especially when there are many repetitive headers (e.g., cookies). - **Reduced Connection Overhead:** Since HTTP/2 uses fewer connections due to multiplexing, it reduces the overhead of setting up and tearing down connections, which can lead to faster communication, especially in environments with higher latency. ### Summary: - **On localhost:** The difference in speed between HTTP/2 and HTTP/1.1 will likely be negligible, though HTTP/2 might be marginally faster due to multiplexing. - **Over the network:** HTTP/2 will generally be faster due to multiplexing, header compression, and reduced connection overhead, especially in scenarios with higher latency or when multiple requests are being made concurrently. Closes #379. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Release Notes - **New Features** - Introduced streaming server rendering support for improved performance and progressive page loading. - Added replay functionality for console logs during server rendering to aid debugging. - Enhanced error handling during server rendering with new configuration options. - Integrated support for HTTP/2 in the node-renderer for better performance. - **Bug Fixes** - Improved error reporting and handling for HTTP requests. - Updated multiple JavaScript dependencies for better stability. - **Documentation** - Updated `CHANGELOG.md` to reflect new features and changes. - **Tests** - Modified tests to accommodate new HTTP/2 request handling and improved error management. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alexey Romanov <[email protected]>
11 participants
react_on_rails currently requires Ruby 2.1, but it's really only a handful of lines that use required keyword arguments. This commit removes those so that react_on_rails is compatible with Ruby 2.0.
This change is