does anyone work on form helper for svelte and others?

[boynet]

I think its good idea to track it here so multiple people will not work on the same stuff

I wonder if there some way of creating the base api in vanilla js and then create simple adapter in each framework?
as its crazy to maintain each feature to all frameworks

[claudiodekker]

Hi @boynet,

Thanks for asking these question(s)!

First off, I'll just be fully transparent about something that our Svelte users might have been wondering at this point: While the Svelte adapter & community is very important to Inertia, development on it has been rather stagnant as of late, simply because the people maintaining it have been busy with other, non-Inertia things. This is totally OK, as it is FOSS after all, but for the Inertia Svelte adapter / project, it does create a bit of a problem. As a result, we've recently been busy to try and resolve this problem, and with a bit of luck we should have more activity on the Svelte side of things in the near future.

I think its good idea to track it here so multiple people will not work on the same stuff

That said, right now, as you might've already guessed, there isn't anyone working on the form helper or other things, but we would really appreciate it if people would want to pick things like this up! To do so without other people working on the same thing, I suggest the following process:

1. Check if someone already created a (draft) PR for it
2. Create a PR towards Inertia (make sure it's descriptive of what you're working on)
3. Mark the PR as 'Draft'
4. (optional:) Mention me in a comment (or on Discord, Twitter etc.) so I can tag the PR with the appropriate labels
5. Work on the PR, and once done, mark it as 'Ready to review' (it'll re-open it the PR)
6. (optional:) Mention me again, so I can tag the PR as needing feedback.

At this point, because of our (too) limited Svelte experience, we likely won't merge the PR directly, although we will welcome community reviews/feedback. Once we're convinced that the PR is in a healthy shape and works as intended, we'll likely merge it.

One thing that I really cannot stress enough, is that we might keep the PR open for a long time, or even reject it altogether, for many different reasons:

1. Once we merge something, we have to maintain/live with it going forward, so 'accepting' code by merging it is something we only do very carefully.
2. With our limited Svelte experience, we might simply not be confident enough that your solution (while 100% functional) is functioning correctly, follows the recommended Svelte approaches, and has the level of code quality we expect from Inertia's codebase.
3. A better solution might've presented itself, whether through someone else's efforts or otherwise.
4. And so forth. There's too many generic reasons for us to reject a PR, but most important to know if this happens, is that by rejecting a PR, we're not rejecting you as a person, but rather the implementation. This does NOT mean your code is 'bad' per-se!

I wonder if there some way of creating the base api in vanilla js and then create simple adapter in each framework? as its crazy to maintain each feature to all frameworks

This is actually what we're trying to do already through the 'Inertia core' (@inertiajs/inertia), with all the framework-specific code living in their own 'adapters' (vue, react, svelte..)

Hope this answers your questions! 👍

[boynet]

Thanks for your answer, so you would recommend before start working on a project with interia+svelte to consider other options?

This is actually what we're trying to do already through the 'Inertia core' (@inertiajs/inertia), with all the framework-specific code living in their own 'adapters' (vue, react, svelte..)

what I ment is to build a frameworkless api and let the framework adapters speak with the api, so 90% of the code will be reusable in all framework

for example
from:

 clearErrors(...fields) {
      this.errors = Object
        .keys(this.errors)
        .reduce((carry, field) => ({
          ...carry,
          ...(fields.length > 0 && !fields.includes(field) ? { [field] : this.errors[field] } : {}),
        }), {})

      this.hasErrors = Object.keys(this.errors).length > 0

      return this
    },

implment it in the base api and let the frameworks adapters call it like:
to:

 clearErrors(...fields) {
      this.errors = BaseFormApi.clearErrors(...fields)

      this.hasErrors = BaseFormApi.hasErrors;

      return this
    },

now making a svelte adapter will be childs game

I have no idea if it possible

[claudiodekker]

Ah, I see what you mean..

Yes, we considered doing this for the form helper (by placing an 'abstract base form' in the Inertia core and extending it within the adapters, like you're suggesting), but decided not to do this at the time, because if we were to accidentally create the wrong abstraction, and an adapter ends up needing a specific change we didn't account for (e.g. regarding reactiveness/bindings), we'd end up needing to release a new breaking @inertiajs/inertia version, which in turn then forces each and every other adapter to get a release just to stay compatible/not break, which isn't worth the risk to us.

Furthermore, the form helper by itself is mostly a really simple class/object anyway, and there's nothing preventing us from reconsolidating them / making that abstraction at a later time.