XMLHttpRequest for boost and likes #850
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
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Plume/Plume#850
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Right now, when boosting or liking an article, the whole page is reloaded.
I think it’s not enjoyable for the user. That’s why I suggest to implement XMLHttpRequest on both those action, to change the values without reloading the whole page.
I want to work on that issue. I’m new to Rust and Plume, so anyone willing to help me (please don’t to the work for me, just point me in the right direction, thanks!) is welcome.
That sounds nice feature.
Plume's frontend development is a little complex.
templates
directoryplume-front/src
To compile WASM file, you need run
cargo web deploy -p plume-front
. And then, files of these types are compiled and copied at Rust's compile time inbuild.rs
.Additionally, you might have to develop API endpoints for boost and like. That will be achieved mostly in
src/routes
directory.Now Plume has API endpoints at
/api/v1
URI. But they requires OAuth authentication to access and you will not prefer it.XMLHttpRequest
(orfetch
) to/~/{BlogName}/{article-slug}/like
, parse HTML in response and check if it succeeded or faild. Or,Is this enough information? Feel free to ask anything.
Development Guide also helps you.
IMO, sending an XHR to a HTML endpoint just to trigger a side-effect is quite a nasty hack. I think we'd be much better off with a separate API endpoint for this.
That's exacty my intention, to XHR the numbers of boosts and likes in one go and update the view arcordingly
Sorry, I was wrong. Some API endpoints like
/api/v1/posts
doesn't require authorization. It's might be better to add endpoints under/api/v1
.Don't worry about it, we all make tiny mistakes like that
A technique I've used is having the form still on the page that submits to an HTML endpoint and using Javascript to add an input named
format
with valuejson
, then submitting the form with FormData. That way if the user disables javascript or the js doesn't load, the form will still have its current behavior and instead of creating a new endoint you just use the same endpoint but change the response based on thatformat
parameterI found the issue for API: #5
would be nice to have!
Isn't this issue a copy or very similar to #591 ?
Ah, you're right. Okay I will close this issue. Track #591. Thanks!