Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not initialize promotions object on startup #5728

Conversation

mamhoff
Copy link
Contributor

@mamhoff mamhoff commented Apr 18, 2024

Summary

Initializing the app with the code prior to this commit would
instantiate the promotions configuration, which is not good because
instantiating it via Spree::Config.promotions leads to the object
being instacached and very, very hard to change.

Also, we currently have to spots in the app where we can configure the
promotion api attributes, and this reduces it to just one by deprecating
the preference :promotion_attributes on Spree::ApiConfiguration.

This includes some commit from #5727 to see the tests through.

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

@mamhoff mamhoff requested a review from a team as a code owner April 18, 2024 12:04
@github-actions github-actions bot added changelog:solidus_api Changes to the solidus_api gem changelog:repository Changes to the repository not within any gem labels Apr 18, 2024
@mamhoff mamhoff force-pushed the do-not-initialize-promotions-object-on-startup branch from c148964 to f06b835 Compare April 18, 2024 12:06
@github-actions github-actions bot removed the changelog:repository Changes to the repository not within any gem label Apr 18, 2024
Copy link

codecov bot commented Apr 18, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.84%. Comparing base (7ba0f98) to head (0f24a5d).
Report is 8 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #5728   +/-   ##
=======================================
  Coverage   88.84%   88.84%           
=======================================
  Files         704      704           
  Lines       16757    16764    +7     
=======================================
+ Hits        14887    14894    +7     
  Misses       1870     1870           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

it { is_expected.to eq(Spree::Config.promotions.promotion_api_attributes) }
end

describe "#promotion_attributes=" do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this also supports pushing new attributes to the array.

config.promotion_attributes << [:name]

# or

config.promotion_attributes.push(:name)

And also removing items from the array. Shouldn't we also support those kind of customizations?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of these are still possible, as the list of attributes is just an array of symbols at the end. I've added some specs to prove it.

Initializing the app with the code prior to this commit would
instantiate the promotions configuration, which is not good because
instantiating it via `Spree::Config.promotions` leads to the object
being instacached and very, very hard to change.

Also, we currently have to spots in the app where we can configure the
promotion api attributes, and this reduces it to just one by deprecating
the preference :promotion_attributes on `Spree::ApiConfiguration`.
@mamhoff mamhoff force-pushed the do-not-initialize-promotions-object-on-startup branch from f06b835 to 0f24a5d Compare May 2, 2024 07:31
@kennyadsl kennyadsl merged commit 4f9c427 into solidusio:main May 6, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog:solidus_api Changes to the solidus_api gem
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants