Followup on https://github.com/rails/rails/pull/45745
`@rendered` is a much better variable for this kind of intermediate
result as that's what is used by DOM assertions.
Right now many helpers have to deal with two modes of operation to
capture view output.
The main one is to swap the `@output_buffer` variable with a new buffer.
But since some view implementations such as `builder` keep a reference
on the buffer they were initialized with, this doesn't always work.
So additionally, the various capturing helpers also record the buffer
length prior to executing the block, and then `slice!` the buffer back
to its original size.
This is wasteful and make the code rather unclear.
Now that `OutputBuffer` is a delegator, I'd like to refactor all this
so that:
- @output_buffer is no longer re-assigned
- A single OutputBuffer instance is used for the entire response rendering
- Instead capturing is done through `OutputBuffer#capture`
Once the above is achieved, it should allow us to enabled Erubi's
`:chain_appends` option and get some reduced template size and some
performance.
Not re-assigning `@output_buffer` will also allow template to access
the local variable instead of an instance variable, which is cheaper.
But more importantly, that should make the code easier to understand
and easier to be compatible with `StreamingBuffer`.
It's really not what it's meant for. `@renderer` is a better use
for this as it's the variable used by the DOM testing helpers.
Ref: https://github.com/rails/rails/pull/45731
Ref: https://github.com/jeremyevans/erubi/pull/33
If the template is compiled with `frozen_string_literals: true`,
then explicitly freezing string is slightly wasteful as it will be
compiled as `opt_str_freeze` instead of a simple `putobject`.
The former has to check wether `String#freeze` was redefined every
time, which while fast is useless extra work.
The i18n gem (https://github.com/ruby-i18n/i18n) has been modified to `freeze`
locale setting values. This could cause the Date helper to not work correctly
under certain conditions. `dup` the configuration values fixes that problem.
Using `create_or_find_by` in codepaths where most of the time
the record already exist is wasteful on several accounts.
`create_or_find_by` should be the method to use when most of the
time the record doesn't already exist, not a race condition safe
version of `find_or_create_by`.
To make `find_or_create_by` race-condition free, we can search
the record again if the creation failed because of an unicity
constraint.
Co-Authored-By: Alex Kitchens <alexcameron98@gmail.com>
Ref: https://github.com/rails/rails/pull/41659
Mutating the attributes hash requires to workaround the mutation
in `find_or_create_by` etc.
One extra Hash dup is not big deal.
Instead we lazily check for pipelining support. `Redis::Distributed`
immediately raise when `pipelined` is called.
Also instead of using `mset` we use a pipelined. The performance
difference is extremly minimal, but it allows us to re-use `write_entry`
hence more shared code and we can speed up `write_multi` with an
expiry.
This commit enhances the `Rails::Command::Base.executable` method to
integrate a new `bin` class attribute and optional `subcommand` arg.
So, for example, `CredentialsCommand.executable(:edit)` will now return
"bin/rails credentials:edit".
Additionally, this commit replaces occurrences of "bin/rails COMMAND",
"rails COMMAND", and "COMMAND" in help messages with calls to
`executable`, for improved consistency.
In #44910, the `credentials:edit` command was fixed to support spaces in
the temporary file path on Windows. This commit applies the same fix to
the `encrypted:edit` command.
Previously configs of the form `config.active_job.X` were only forwarded to
`ActiveJob::Base`. This teaches Active Job to set them on `ActiveJob` directly
instead, if the setter exists.
For consistency, this more or less mirrors the way that Active Record does it.
Co-authored-by: Adrianna Chang <adrianna.chang@shopify.com>
Co-authored-by: Sam Bostock <sam.bostock@shopify.com>
---
Fix use_big_decimal_serializer Rails 7.1 default
This config should be enabled for new Rails 7.1 apps, or apps that have updated
their config to `load_defaults 7.1`, not disabled.
This also clarifies the config accessor comment.
---
Add contributor documentation comment to load_defaults
The process for introducing a change in behavior in Rails can be confusing to
new contributors, so a comment is added roughly explaining how to do so, and
what belongs in `load_defaults` and `new_framework_defaults`.
This comment is aimed at contributors, not consumers, so it is added within the
method, rather than above it.
