Deprecation of framework-agnostic widgets

[SamMousa]

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

Question / discussion

https://github.com/surveyjs/survey-library/issues/2757#issuecomment-953610221

Thought I'd move this to a separate issue since it is not related to any question type in particular. The move away from framework agnostic (rendering) code means that any custom widget will probably not have support for all frameworks (since the person building it is probably only using one framework).

While I understand the possible benefits of rendering using the frameworks specific mechanics, forcing implementors to do this will make it less portable and harder to contribute. I think we can get the best of both worlds by offering a hybrid approach;

• Allow custom widgets to render as they do now via a simple render call.
• Allow frameworks specific overrides for optimization.

Imagine I have a custom widget that only renders a simple canvas element (and loads some JS for interaction), the gains from any type of framework rendering are negligible, but the extra effort required to support all frameworks (of which I probably at most 1 in my code base) is significant.

[tsv2013]

Right now we already have both approaches implemented:

• Allow custom widgets to render as they do now via a simple render call.
• Allow frameworks specific overrides for optimization.

[SamMousa]

I know; but you mentioned that you are considering removing the simple render method?

[tsv2013]

The thing is that custom widgets become not extension point but rather more implementations of missing functionality of SurveyJS library: select2 with lazy loading and find feature, tagbox, date time picker, mask edit and so on. We have plans to implement all these features out of the box. As far as I understand after all must have functionality will be implemented, no one except SurveyJS team will create a cross-platform custom widget. That's why I think we don't need it - almost all scenarios will be covered via native framework components used via "renderAs" option.

[SamMousa]

But you might not want to have all question types in the core. (I'm happy to demo you some of my custom question types if you're interested)

I think it'd be a loss if we lose the framework agnostic way of rendering (also because I don't think it requires much code maintenance to leave it in). For simple things, like rendering a single DOM element, frameworks are just overhead and having a render function is the perfect solution.

[andrewtelnov]

@SamMousa If you are talking about our core library and master branch then we have to support all plaforms. Otherwise it would be hard to support it. We have change our rendering mechanizm. We need it for Creator V2, since Creator V2 already has Knockout and React versions and later will have Angular and Vue versions. You can override the default rendering and use it's own. You can support it only for one platform. Here is the exampe for react. Custom widgets allow to support all platforms, but you could not use react or angular or vue components there.

PS: We want to implement mask, date edit and a better dropdown/tagbox with filtering out of the box for all plaforms. It is in our plans.

Thank you, Andrew

[SamMousa]

I think we're misunderstanding each other. :)

From my point of view, for most question types, there is no advantage to having the question types themselves use the full framework component logic. If we don't need the framework features like input binding etc, than there is no downside to using a simple render function and manual DOM manipulation. Because even when doing that it should be able to plug that in to any framework rendering pipeline, this is something the core library should do then.

For example, when a question gets rendered you pass in an element to the render function, this could be an element in shadowDOM if the used framework happens to use shadowDOM, or it could be virtual DOM etc, it doesn't matter. From the question type perspective it gets a DOM element and adds the children that it needs.

Afaik there is no issue with using framework-agnostic code inside a framework, the issue is the other way around, using React code in Vue will at the very least require extra work. So then you're stuck; forced to implement 1 render method for each framework.

As far as I understand after all must have functionality will be implemented, no one except SurveyJS team will create a cross-platform custom widget.

That really depends on the type of integrations you offer, anyone creating a custom question type using the current samples that use a pure JS render functions will be cross-platform. If you remove that feature, you're right, few people will bother spending the time implementing code that they don't use. But if you leave it in, people can choose to not use framework specific code.

Anyway, guess I'll found out if anything breaks when V2 launches. It looks really cool btw!