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

feat!: Make load/create/update/delete entity authorization result interfaces consistent #253

Conversation

wschurman
Copy link
Member

@wschurman wschurman commented Feb 19, 2025

Why

The idea here is to unify the pattern that we use for loading across mutations as well.

Currently, loading looks like:

await TestEntity.loader(vc).enforcing().loadByIdAsync();
await TestEntity.loader(vc).withAuthorizationResults().loadByIdAsync();

But mutations still look like:

await TestEntity.creator(vc).setField(...).enforceCreateAsync();
await TestEntity.creator(vc).setField(...).createAsync();

await TestEntity.updater(entity).setField(...).enforceUpdateAsync();
await TestEntity.updater(entity).setField(...).updateAsync();

await TestEntity.enforceDeleteAsync(entity);
await TestEntity.deleteAsync(entity);

This is proving to be too error-prone. Mostly with the deleteAsync/enforceDeleteAsync distinction not being explicit enough since the returned result from deleteAsync is rarely used in application code.

This PR proposes changing the mutations to be more like the loading:

await TestEntity.creator(vc).enforcing().setField(...).createAsync();
await TestEntity.creator(vc).withAuthorizationResults().setField(...).createAsync();

await TestEntity.updater(entity).enforcing().setField(...).updateAsync();
await TestEntity.updater(entity).withAuthorizationResults().setField(...).updateAsync();

await TestEntity.deleter(entity).enforcing().deleteAsync();
await TestEntity.deleter(entity).withAuthorizationResults().deleteAsync();

Closes ENG-15049.

How

Add layer in-between entity methods and mutator factories that requires dictating enforcing or withAuthorizationResults to vend a mutator.

Note that this will likely require a codemod in any application that uses it. But the codemod is pretty straightforward.

Test Plan

This has full test coverage.

Copy link

codecov bot commented Feb 19, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (275c63d) to head (10a0a8f).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #253   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           72        78    +6     
  Lines         1985      2033   +48     
  Branches       279       278    -1     
=========================================
+ Hits          1985      2033   +48     
Flag Coverage Δ
integration 100.00% <100.00%> (ø)
unittest 100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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

@ide
Copy link
Member

ide commented Feb 20, 2025

Looks fine but I think it'd be a good idea to push out a breaking change to Entity where everything is enforcing by default and you need to call unenforcing() (or withAuthorizationResults()). We talked about this before I believe. Almost all our callsites use enforcing() and we'd be making the common case the default.

Copy link
Member Author

wschurman commented Feb 20, 2025

Yep. This change to making it explicit should help with the proposed breaking change that changes the default (assuming upgrades are done one-by-one version). In the current state though (before this PR) we can't do the breaking change without creating risk of implicit return type changes which are harder to detect (wouldn't necessarily show up for tsc run); for this package, we should strive to make all breaking changes detectable via tsc.

Copy link

linear bot commented Feb 22, 2025

Copy link
Member Author

wschurman commented Feb 24, 2025

Merge activity

  • Feb 23, 10:20 PM EST: A user started a stack merge that includes this pull request via Graphite.
  • Feb 23, 10:21 PM EST: Graphite rebased this pull request as part of a merge.
  • Feb 23, 10:23 PM EST: A user merged this pull request with Graphite.

@wschurman wschurman changed the base branch from @wschurman/02-19-chore_upgrade_typescript_and_related_packages to graphite-base/253 February 24, 2025 03:20
@wschurman wschurman changed the base branch from graphite-base/253 to main February 24, 2025 03:20
@wschurman wschurman force-pushed the @wschurman/02-19-feat_make_load/create/update/delete_entity_authorization_result_interfaces_consistent branch from a9b658b to 10a0a8f Compare February 24, 2025 03:21
@wschurman wschurman merged commit 4d56065 into main Feb 24, 2025
2 checks passed
@wschurman wschurman deleted the @wschurman/02-19-feat_make_load/create/update/delete_entity_authorization_result_interfaces_consistent branch February 24, 2025 03:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants