Add some feedback when performing some actions #552
No reviewers
Labels
No labels
A: API
A: Backend
A: Federation
A: Front-End
A: I18N
A: Meta
A: Security
Build
C: Bug
C: Discussion
C: Enhancement
C: Feature
Compatibility
Dependency
Design
Documentation
Good first issue
Help welcome
Mobile
Rendering
S: Blocked
S: Duplicate
S: Incomplete
S: Instance specific
S: Invalid
S: Needs Voting/Discussion
S: Ready for review
Suggestion
S: Voted on Loomio
S: Wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Plume/Plume#552
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "action-feedback"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Here is an example of what it looks like (this is just a test, in reality you can only have one of these messages at the same time):
I don't know if there is a simpler way to do it. Also, I added
msg: Option<FlashMessage>to almost all routes to be sure that if a message was present it would be rendered, but maybe it is not necessary and only make the code harder to read? And maybemsgshould go inPlumeRocketas it is used almost everywhere?Fixes #468
Codecov Report
Considering how it must be everywhere, I think it can go in
PlumeRocket, as well as in templateBaseContext. AlsoBaseContextcould implementFrom<PlumeRocket>so it is easier to build and reduce duplicationmaybe we should hold on committing the translations in such prs?
do then regularly elsewhere
this is supposed to be
but i just realised that fuzzy means it was auto translated…
@igalic I don't really know… it is true it pollutes a little bit the diff, but at the same time it makes sense to have them with the change in the interface.
Yes, it was auto-translated. Once it will be on Crowdin, you will be able to fix it. 😉
I'd be to not pollute pr with this, and have something that autocommit the changes once a week, or after each merge
👀
@ -17,0 +27,4 @@&Connection,&Catalog,Option<User>,Option<(String, String)>,why not implementing
From<PlumeRocket>for Context? It will auto implementInto<Context>for PlumeRocket, and you should be able to useinto()with no need to import this trait everywhere@ -17,0 +27,4 @@&Connection,&Catalog,Option<User>,Option<(String, String)>,Because Rust is complaining about the fact that all the parameters of the trait comes from another crate, and that it could cause conflicts, while I don't think it can? 🤷♀️ But yeah, I tried it, and it doesn't work.
@ -17,0 +27,4 @@&Connection,&Catalog,Option<User>,Option<(String, String)>,ho, it's because BaseContext is not a true struct but a typedef to a tuple of basic types (in theory it could cause conflict, because the exact same trait can be implemented in plume-model, thus creating a conflict). This mean we can either convert BaseContext to be a true type, or implement Into in plume-models. I've tried the first one, but it requires some small but ugly changes so I'm not sure it would be better (you can take a look at the patch here)
👍
Do you want me to apply your patch before merging?
It was just to show what I came up with, but having
&(&rockets).into()everywhere is definitely worse than importing a trait