-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[CL-298] async-actions 2.0: Context string #9396
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
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9396 +/- ##
==========================================
+ Coverage 28.05% 28.09% +0.04%
==========================================
Files 2391 2398 +7
Lines 70521 70624 +103
Branches 13207 13216 +9
==========================================
+ Hits 19782 19840 +58
- Misses 49174 49211 +37
- Partials 1565 1573 +8 ☔ View full report in Codecov by Sentry. |
No New Or Fixed Issues Found |
Fixed! |
import { Directive, Input } from "@angular/core"; | ||
|
||
import { AsyncContextProvider } from "./async-context-provider.abstraction"; | ||
|
||
@Directive({ | ||
selector: "[bitAction][context]", | ||
providers: [{ provide: AsyncContextProvider, useExisting: BitAsyncContextDirective }], | ||
}) | ||
export class BitAsyncContextDirective implements AsyncContextProvider { | ||
@Input({ required: true }) | ||
context: string; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: Maybe "Async Group" would be a better name? Might clash with the form group concept
<div>
<button [bitAction]="delete" group="vault-table">Delete item</button>
...
<div>
or maybe
<div>
<button [bitAction]="delete" asyncGroup="vault-table">Delete item</button>
...
<div>
or
<div>
<button [bitAction]="delete" actionGroup="vault-table">Delete item</button>
...
<div>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I would like group
or actionGroup
if it didn't collide with formGroup
. I don't dislike context
though--maybe we can see what others think?
{/* TODO: Add ButtonLikeAbstraction to bitMenuButton */} | ||
{/* <Story of={stories.GroupedInMenu} /> */} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need some help with this, the component has changed since I last worked with it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generally love the changes here. I still need to take a deeper look at AsyncActionsService
, but some initial thoughts:
|
||
# Async Actions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add an import example above the title?
These directives replace the older `appApiAction` directive, providing the option to use | ||
`observables` and reduce clutter inside our view `components`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a jsdoc @deprecated
tag to appApiAction
and link to this documentation?
|
||
disabled = false; | ||
private state$!: Observable<State>; | ||
|
||
@Input("bitAction") handler: FunctionReturningAwaitable; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a JSdoc comment on this input that describes it and explicitly mentions the arrow function requirement?
```html | ||
<form [formGroup]="formGroup" [bitSubmit]="handler"> | ||
<button bitButton bitFormButton type="submit">Submit</button> | ||
</form> | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🌱 🤔 You know, I wonder how ergonomic this really is when compared to:
<form [formGroup]="formGroup">
<button bitButton [bitAction]="submit" context="my-form" type="submit">Submit</button>
</form>
Maybe less ways to do the same thing is better? It feels a bit odd that submit actions are on the form vs the button.
(I wouldn't want to deprecate anything in this PR, just curious what you think.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually thinking the opposite, putting the submit action on the button feels odd to me 😄 Here are some reasons why:
- Regular angular forms have the submit event on the form
<form [formGroup]="formGroup" (ngSubmit)="onSubmit()">
...
<button type="submit">Submit</button>
</form>
- Most likely an edge case, but HTML does support multiple submit buttons:
<form [formGroup]="formGroup" (ngSubmit)="onSubmit()">
...
<button type="submit">Submit 1</button>
<button type="submit">Submit 2</button>
<button type="submit">Submit 3</button>
</form>
- No submit buttons are also supported by using the "enter" key (not the most accessible design but still)
<form [formGroup]="formGroup" (ngSubmit)="onSubmit()">
...
</form>
```html | ||
<button bitButton [bitAction]="handler" context="emergency-contact">Accept</button> | ||
|
||
<button bitButton [bitAction]="handler" context="emergency-contact">Reject</button> | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to also support passing a template reference variable to context
? Naming things is hard, and this gets around that (also prevents collisions by default)
<div #myDiv>
<button bitButton [bitAction]="handler" [context]="myDiv">Accept</button>
<button bitButton [bitAction]="handler" [context]="myDiv">Reject</button>
</div>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, yeah sure, as long you can compare them by reference 🤷
But then again, if you've already named the template reference then you could just reuse that name as a string
<div #myDiv>
<button bitButton [bitAction]="handler" context="myDiv">Accept</button>
<button bitButton [bitAction]="handler" context="myDiv">Reject</button>
</div>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ Why split this into a distinct directive? Why not just make context
an input on BitActionDirective
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎨 This implementation now feels redundant with the addition of context
.
Is anything stopping us from updating this to:
@Directive({
selector: "button[bitFormButton]",
hostDirectives: [BitActiveDirective],
})
export class BitFormButtonDirective {
context = inject(BitSubmitDirective).context;
}
(I haven't really used hostDirectives
before, I could be making an incorrect assumption about how it works.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, not sure I follow, what is redundant? You still need something to bind to regular buttons (e.g. cancel) and submit buttons (given that we don't move bitSubmit
to them)
🎟️ Tracking
CL-298 async-actions 2.0: Context string
📔 Objective
This PR adds more flexibilty to async-actions by allowing developers to create arbitrary groups of async-actions buttons. Examples include:
It is the second attempt at improving
async-actions
based on @willmartian suggesting an interesting way of simplifying the context handling, it's more manual but also much less complex:📸 Screenshots
Everything looks and works the same
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:
) or similar for great changes:memo:
) or ℹ️ (:information_source:
) for notes or general info:question:
) for questions:thinking:
) or 💭 (:thought_balloon:
) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:
) for suggestions / improvements:x:
) or:warning:
) for more significant problems or concerns needing attention:seedling:
) or ♻️ (:recycle:
) for future improvements or indications of technical debt:pick:
) for minor or nitpick changes