Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Element inheritance model #12

Open
AgrawalAmey opened this issue Mar 17, 2016 · 7 comments
Open

Element inheritance model #12

AgrawalAmey opened this issue Mar 17, 2016 · 7 comments

Comments

@AgrawalAmey
Copy link

Custom element to custom element inheritance is what I suppose central to idea of web components and also of importance to biojs. Polymer provided this option in v0.5 but v1.0 still does not though it is on their to-do list. Currently it provides behaviors for a inheritance. I suppose we should provide abstraction allowing custom elements inheritance/behavior irrespective of framework they are built with using a biojs core library. Also including html auto binding templates(polyfills) and other features which help in custom element to custom element interaction in the biojs core should make it easier for someone using multiple biojs elements, else he might have to resort to polymer or some other framework for the same while the elements he is using might not be developed using the same framework adding unnecessary overheads.

@wilzbach
Copy link
Member

help in custom element to custom element interaction in the biojs core

I am not sure whether we really will have a core lib. It makes the integration with other libraries usually more difficult and requires a lot of standardization in a still new area. Web components already provides with a unified API - the Dom itself!

However there are also a couple of use cases where biojs components will share a core lib - a current example are the io modules:

https://github.com/biojs/biojs-io-parser

For use cases like data binding or yours with element inheritance, a user should be free to use his favorite framework. This makes his life a lot more productive after all. We might as a community provide a library for this and maybe if it turns out to be good - it will become a standard.

Do you have an example where this needs a common "core" for all components?

@emepyc
Copy link

emepyc commented Mar 17, 2016

I agree with Seb,
In a general sense, biojs shouldn't try to fix the current web components
issues due to lack of maturity in the standards or tooling. I mean, if the
issue is directly related with web components themselves, a solution should
be addressed at the web components level and not the biojs level.

On Thu, 17 Mar 2016 at 11:51 Seb [email protected] wrote:

help in custom element to custom element interaction in the biojs core

I am not sure whether we really will have a core lib. It makes the
integration with other libraries usually more difficult and requires a lot
of standardization in a still new area. Web components already provides
with a unified API - the Dom itself!

However there are also a couple of use cases where biojs components will
share a core lib - a current example are the io modules:

https://github.com/biojs/biojs-io-parser

For use cases like data binding or yours with element inheritance, a user
should be free to use his favorite framework. This makes his life a lot
more productive after all. We might as a community provide a library for
this and maybe if it turns out to be good - it will become a standard.

Do you have an example where this needs a common "core" for all
components?


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#12 (comment)

@AgrawalAmey
Copy link
Author

@greenify Surely the need for core arises only in certain use cases, certainly most of which would become redundant with developing web components specs as pointed by @emepyc . But certain use cases would still persist. For example there exists a polymer parser element which I would like to add some extra functionality but my framework of choice is rather different say Aurelia. The main aim for the core would be to generate a common Js API which can add uniformity to the platform and make different framework work together well. For true inheritance across different frameworks including Js, we would certainly need to force some standardization as I understand the situation.

@wilzbach
Copy link
Member

As pointed out above we do want to have a common library (aka core) for parsers, see also #6

Moreover as pointed out you can use the Dom as Api - even for parsers. Maybe you could provide us with the concrete example and show same pseudo code how you imagine it to work in BioJS

@AgrawalAmey
Copy link
Author

Sure, I would try to build a basic example of what I want to build.

@AgrawalAmey
Copy link
Author

I have tried do some experimentation thought could not finish them as i wished. Considering the time constraints I should discuss the conclusions. When we have native support for web components inheritance using DOM works without that extent of complication, but when the web component specs are polyfilled it doesn't seem to be that straight forward (or may be i do not understand how webcomponents.js works). So as @emepyc said it will be addressed with time, and surely take quite an effort to fix it on own. But then again this would close doors for us to use element inheritance for cases like common parser API as @greenify mentioned before.

@appunnicer13
Copy link

I think now we have basic support for Inheritance in web components v1 standard . The time is ripe for Biojs3. As you can see many examples have been given at https://developers.google.com/web/fundamentals/getting-started/primers/customelements . Well we should consider moving forward with Webcomponents now. Polymer 2.0 is around the corner , which also supports native use of web components . Hope to revive this discussion further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants