Best way for getting the response without devalue

[karchung0930]

The +page.server.js has something like this:

return {
    contents: 'some data'
}

Then on front-end:

import { deserialize } from '$app/forms';

async function callAPI() {
    const requestContents = await fetch('?/api', {...});
    const contents = deserialize(await requestContents.text());
    const myData = contents .data.contents;
}

The buttons will trigger an async function to call the API like so <button on:click={callAPI}></button>

The reason I don't use form with form data and progresive enhance is that there are many buttons, I think it doesn't make sense to have many forms to trigger the API?
For example:

{#each Array(10) as _, index (index)}
    <button on:click={callAPI}></button>
{/each}

Instead of using forms which I think is not suitable:

{#each Array(10) as _, index (index)}
    <form method="POST" action="?/callAPI" use:enhance={formAction}></form>
{/each}

If so, do the deserialize way above is correct and best way to do it?

[brunnerh]

What are you trying to do here?
Why are there many buttons?
How is the API data used?

Forms can have any number of buttons and pages can have any number of forms if necessary.
What the best approach is usually depends on the circumstances.

Though if you do everything via JS, the form is guaranteed to not work, if the JS fails to load. That should always be a consideration when circumventing regular form submission logic.

[karchung0930]

@brunnerh Hi, thanks for responding!

1. I'm trying to get the data from the database by calling the API.
2. There are many buttons because I'm fetching the data by post's title. One button = one post's title, assume there are 100 posts then there would be 100 buttons.
3. As I click the button, it should call the API in the backend to get the data. That's the reason I've made one async function and all the buttons can call this function. The API will then send the data back to front-end.

In this case, I think not logic to make 100 forms for this? ( I guess ).
Another question, back to the topic, since I'm returning the data as:

return {
    contents: 'some data'
}

Therefore I use the deserialize. Is there any better way of returning the data or retrieving the data?

[brunnerh]

That sounds like an alternative design would be to have links to the posts and load them on separate page via the load function, but if you want to load them on the current page you can use an API call. Personally, if time permits, I would still use links that can show the posts on a separate page but progressively enhance those by intercepting the click (stopping navigation via preventDefault) and loading the posts via JS.

I would probably not use a form action for this but a custom endpoint as defined in a +server.js file. Those can return raw Response objects containing data in whatever format you want. There are utility functions like json to generate a JSON response as well. Such responses do not need special deserialization logic on the client.

[karchung0930]

Thanks for the detailed explanation! Can I understand as you would prefer define the API in +server.js with tge utilities function
json over using deserialize with named actions in form?

[brunnerh]

Yes, form actions are designed to be used with forms and by default return their data to the special form property. So if the performed action is not intended to be used in a form at all, it does not make as much sense to use a form action.

You can of course still use a form action and deserialize its data for convenience (e.g. this supports more data types and you can have many different form actions on a single page), the assumed intent might just be a bit off, then.