XMLHttpRequest for boost and likes #850

Open
opened 12 months ago by freyja_wildes · 9 comments

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.

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.

  • HTML (Ructe template) files are present under templates directory
  • CSS (SCSS) files are included in themes. You can see about theme development at Creating a theme page
  • Sources of JavaScript (WASM) file are present under plume-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 in build.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.

  • You might send a request via XMLHttpRequest (or fetch) to /~/{BlogName}/{article-slug}/like, parse HTML in response and check if it succeeded or faild. Or,
  • You can add API endpoint for this purpose.

Is this enough information? Feel free to ask anything.

That sounds nice feature. Plume's frontend development is a little complex. * HTML (Ructe template) files are present under `templates` directory * CSS (SCSS) files are included in themes. You can see about theme development at [Creating a theme](https://docs.joinplu.me/guide/creating-themes/) page * Sources of JavaScript (WASM) file are present under `plume-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 in `build.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. * You might send a request via `XMLHttpRequest` (or `fetch`) to `/~/{BlogName}/{article-slug}/like`, parse HTML in response and check if it succeeded or faild. Or, * You can add API endpoint for this purpose. Is this enough information? Feel free to ask anything.

Development Guide also helps you.

[Development Guide](https://docs.joinplu.me/contribute/development/) 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.

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

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.

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

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 value json, 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 that format parameter

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 value `json`, then submitting the form with [FormData](https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects#Retrieving_a_FormData_object_from_an_HTML_form). 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 that `format` parameter

I found the issue for API: #5

I found the issue for API: #5

would be nice to have!

would be nice to have!
Sign in to join this conversation.
No Milestone
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.