-
Notifications
You must be signed in to change notification settings - Fork 4
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
Refactor: {{action}}
helper usage, the sequel
#896
Draft
DrumsnChocolate
wants to merge
9
commits into
refactor/action_helper_usage
Choose a base branch
from
refactor/action_helper_usage_electric_boogaloo
base: refactor/action_helper_usage
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Refactor: {{action}}
helper usage, the sequel
#896
DrumsnChocolate
wants to merge
9
commits into
refactor/action_helper_usage
from
refactor/action_helper_usage_electric_boogaloo
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## refactor/action_helper_usage #896 +/- ##
================================================================
- Coverage 13.24% 12.95% -0.30%
================================================================
Files 455 456 +1
Lines 3194 3189 -5
================================================================
- Hits 423 413 -10
- Misses 2771 2776 +5 ☔ View full report in Codecov by Sentry. |
DrumsnChocolate
added a commit
that referenced
this pull request
Nov 5, 2024
…er_usage_electric_boogaloo
DrumsnChocolate
force-pushed
the
refactor/action_helper_usage_electric_boogaloo
branch
from
November 5, 2024 22:33
8ab55a1
to
4ed2b17
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
bases on #635
ref #899
may require a third PR after this
New prevent-default helper
This PR also introduces a new template helper:
prevent-default
. It is used to wrap the action we assign to be executed when an event takes place. Specifically, it adds a call toevent.preventDefault()
. Why would we do this in a helper? Well:e.preventDefault();
calls.preventDefault
should take place in the template, because that's where it is easiest to determine.To elaborate on point two, when we have the following action:
Then a template with
requires a call to
e.preventDefault()
:otherwise the page is reloaded automatically (because that's what a submit event on a form does, apparently.) Now, suppose instead the template contains
then we don't need a
e.preventDefault()
call... See how that's confusing? Sidenote: in reality the underlying ComponentForDoingSomething generally still performs a call toe.preventDefault
, but that's none of our business, since principles like dependency inversion dictate that we do not concern ourselves with the implementation details of a child component, but only with the parts we can 'see' of that child component.Now let's make the point even better: if we have a problematic template that contains both of these types of usages:
then what do we do? We need to call
e.preventDefault()
for one element in the template, but not for the other. But that's easily solved with the new helper: