Svelte component (Feature request)

[amit777]

Are you requesting a feature, reporting a bug or asking a question?

I noticed that there are components for jQuery, React, Angular and Vue. Would it be possible to also have a Svelte component?

[dmitry-kurmanov]

Hello!

We will add the feature to our todo list but can't give any estimations. As a workaround you could use knockout or vue version in your svelte app right now. It requires additional dependencies but works ok.

Thanks, Dmitry SurveyJS team

[dmitry-kurmanov]

@amit777 hello! Please also look at my hobby project https://github.com/dmitrykurmanov/survey-standalone. It is Svelte3 + survey-core implementation of SurveyJS. Now only radiogroup works there. Feel free to create an issue with a feature request.

[SamMousa]

I know this hasn't seen interest in a while, but it might be time to reconsider.

Currently several frameworks are supported: Angular, Vue, React, Knockout and jQuery.

All of these frameworks have one thing in common: they require runtime inclusion of files.

Supporting all of these frameworks has several major drawbacks:

• Cannot use framework X renderer inside latest version of framework X
• Some categories of bugs, like frontend rendering, need to be fixed and tested on each framework separately
• Contributions are significantly harder to do because they need to be implemented across frameworks spanning 2 decades

This brings me to Svelte. While Svelte is a framework, it compiles to pure javascript without runtime dependencies. By definition this means that using a Svelte component is easy to do from within each of the mentioned frameworks.

Because of this fact, moving to a UI implementation in Svelte could even reduce the need for framework specific implementations incrementally.

• Implement a Survey component in Svelte (use above fork as inspiration)
• Change implementation of framework specific subcomponent to be an adapter for the framework specific subcomponent.

From the perspective of an application built in a framework, say Vue, it is totally irrelevant of the Survey component and subcomponents are also implemented in Vue; as long as there is an adapter that allows for clean integration it doesn't matter how SurveyJS is built internally.

Take a look at the boolean checkbox component for example. In Vue it is implemented here: https://github.com/surveyjs/survey-library/blob/master/src/vue/boolean-checkbox.vue In React it's implemented here: https://github.com/surveyjs/survey-library/blob/master/src/react/boolean-checkbox.tsx

All of this is code duplication that makes the whole development cycle more complex. Bugs sometimes happen for one platform not the other. There are bound to be inconsistencies between the implementations.

I'd love to hear your thoughts on this!

[dmitry-kurmanov]

@SamMousa thanks for the interesting thoughts. Some times ago I had the same thoughts and also became to the conclusion that Svelte is the best instrument to create a "framework agnostic" library solution. But in the SurveyJS team we decided not to use this approach because of some reasons :

1. A marketing reasons. A lot of developers want to use a "native" framework library. In most cases fact you are right and it is not important how the library is built inside but for many developers it is not a rational decision but an emotional one.
2. In some rare cases users of the library might want to use for example React components inside it. For example, using some React components as survey questions. Here is the example of that integration: https://surveyjs.io/Examples/Library?id=custom-widget-react-select&platform=Reactjs&theme=defaultV2#content-result. With the "framework-agnostic" approach it might be a problem with that kind of cases (two-way binding etc)
3. Legacy. We already using the core library + native frameworks implementations so it will be hard and expensive to change it.

[SamMousa]

1. Can't really argue with this, though marketing wise you'd probably get the same effect if you called it SurveyJS with framework native modules. Note that even the individual framework specific component like ReactBooleanCheckbox could be created from reusable Svelte components.

2. I think this is a technical challenge that we can actually solve relatively easy. I'm fairly confident that doing it all in the framework is not a strict requirement for that, and it probably isn't the cleanest approach in either case.

3. This is what I thought at first as well, but I think this can be significantly reduce if we do it incrementally:

   • Core library is already framework agnostic
   • We could implement an extra framework first (Svelte)
   • [optional] We can probably immediately phase out the "pure" jquery and knockout implementations in favor of the Svelte one
   • One by one we can change a question type in one of the implementations to be a wrapper for the Svelte implementation

This gradual approach carries very little risk and the upfront costs (in time) are also significantly reduced. In the long run it will save time on support and development due to less technical debt. While I truly admire what you guys have built, I do see the number of supported frameworks as a risk, because the more you build the more the overhead increases.

I'll do some more research and maybe consider implementing some stuff in Svelte just to see what the pros and cons are in practice.

[tsv2013]

The thing is that React, Angular and Vue customers want to work with SurveyJS components in a native way, use "native" 3rd party libraries, expect "native" lifecycle and events and so on. And when they want to override some built-in behavior they want to do it in a "native" way instead of learning another one framework and struggling with how to integrate it.

If we aren't be a library for developers but be a kind of black box we could go this way. But we're working for developers, trying to make our products usage easy and convenient.

[SamMousa]

Would you consider a merging PR that implements Svelte just as the other frameworks?

Seeing as it has no dependencies this could essentially replace the knockout-js renderer in the future.

I've got a developer looking into an estimate as we speak but of course I'd want to merge this back upstream instead of maintaining a fork.

[tsv2013]

@SamMousa We discussed merging of the svelte implementation into our repo and decided that we are not ready to do it. We can propose you to create your own repo let's say for a "survey-svelte-lib" library that will reference our "survey-core" package and implement svelte specific rendering for survey model. You can publish this "survey-svelte-lib" package in NPM or other package registry and use in your applications.

[SamMousa]

I'm aware I could do that, but it would mean that I'm constantly tracking your work. Instead of having it as part of the core project where any breaking change would be detected early via CI / automated testing.

[tsv2013]

Unfortunately right now we don't have resources to maintain another one framework and add new features to it. May be in future we could return to this discussion but not at this moment.

[m-uipath]

I hope things get change soon, and considering Svelte as one of core frameworks in the library.

[teamw4me]

One more vote for Svelte; I don't want to waste cycles researching (and supporting) a hack via importing another framework

[SamMousa]

One more vote for Svelte; I don't want to waste cycles researching (and supporting) a hack via importing another framework

You refer to the knockout framework in that case I assume? There is no reason to import a more complicated framework just to use SJS in Svelte.

I hope things get change soon, and considering Svelte as one of core frameworks in the library.

I don't really agree with this sentiment to be honest. The premise being that SJS should support any frontend framework with a full implementation seems false to me. (The SJS team doesn't agree with me on this, or hasn't in the past) Currently the core library code is not framework dependent, only the different question renderers are. They heavily rely on inheritance and implement a renderer subclass for each supported framework. I don't get why this is needed at all. Instead why not have a renderer for the built in question types in something lightweight with no runtime dependency (doesn't have to be Svelte, but it is a sensible choice). Then implement 2 adapters for each framework you want to support:

1. The survey component, which is essentially a bare wrapper around the framework-less survey component.
2. A question adapter that can easily create a new question type from a framework component.

There will never be a situation where the core team has time to support all front end frameworks and many of the frontend bugs arise for one framework but not the other, because rendering code is not actually shared between them. From a technical perspective there is no benefit to rendering the whole survey in framework X since the library abstracts this; I don't need to have event bubbling according to my framework's system. From my point of view the survey component is a black box with depth 1 and I want to use it like that. If I need to manipulate it I use the exposed core API that is documented.

[rumack]

As a workaround you could use knockout or vue version in your svelte app right now. It requires additional dependencies but works ok.

I don't expect the library to have a native Svelte implementation, but it seems impossible to make it work with Svelte at all.

I can't figure out how to make the questions render in Svelte with the Vue library. Could anyone point me in the right direction?

[mattyg]

+1 for this request - would love a svelte component

[gmanfredi]

+1 for this request -- Svelte support

[JaneSjs]

Hello, You can use the survey-js-ui package to integrate SurveyJS Form Library to a Svelte app. Please refer to the following demo: View Stackblitz.

A similar issue was discussed at SurveyJs with Svelte latency.