I do not understand this ?! about custom-elements-manifest HOT 15 CLOSED

The custom-elements.json will most likely be generated based on JSdoc, yes.

from custom-elements-manifest.

web-component-analyzer already uses JSDoc directly. JSDoc is one of its output formats.
We do need such a data format for generating API docs, see api-viewer-element.

Just to clarify: running analysis in browser based on JSDoc is something that Polymer tools supported with hydrolysis that was used for Polymer 0.5 and 1.x API documentation.

That resulted in custom elements being analyzed in browser, every time user refreshed a page.
I believe this was done on purpose as an attempt to not depend on any npm-based tooling.
Nowadays we don't follow that approach anymore (it existed because of HTML imports).

I hope this makes is a bit more clear.

from custom-elements-manifest.

Hi @frank-dspeed,

I hope my suggestion didn't upset you in some way. If so I apologize. That was not my intention, but I find I'm not so good at being that clear. I have the (quaint?) belief that the more productive programmers are, the better the world will be, which will only help to strengthen and enlarge the programmer community as well. Reducing boilerplate, and finding the easiest approach, when appropriate, is not meant to eliminate jobs, only make the jobs more fun and interesting and provide a better product (I hope). In my eyes, working with JSON is easier than working with interpreters and parsers, but that's my bias, I guess.

I think I get where you're coming from (maybe?). Some applications (like tax software, perhaps, or data visualization solutions) benefit, I think, from being data driven, in order to reduce boilerplate code. I suspect Github does as well.

Other applications may not, and making it so could impose unnecessary restrictions. Some might be best to start out less structured, and with time, make it more structured. I don't believe in one size fits all, and I try not to judge, though I admit I have a bias toward looking for data driven approaches on the early side. And yes, I think for large applications, that may be the best way to make it scale. Would you judge me badly if I admitted that I have worked with some applications that were data driven, and it turned out okay?

In case it came out wrong, my suggestion is meant to (possibly) help reduce friction between those of us who want to create reusable components across frameworks, but certainly cater to React as well, in as easy a manner as possible.

So a developer would (manually) write a web component, then, with JSDocs, auto generate both a JSON file, and a react wrapper, with one (or two) scripts. The JSON file already serves other purposes (like providing autocomplete for VS Code, for example).

Do you see any limitations I'm missing, why JSON wouldn't be able to automate the creation of this wrapper? Or why developers would prefer to write these wrappers manually?

If you create a library that does that via JS parsing / reflection, go for it, and I may very well use it, and certainly give it a star and all that. There are some libraries that have found creative ways of bridging the gap, but they currently seem to either rely on deprecated features of react, or require modifying a pragma file, which may be a difficult sell in some cases. It just seems like it would be relatively easier to do if there's already a JSON file.

Apologies again.

from custom-elements-manifest.

There is no need to apologize.

Custom-elements.json has a lot of valid usecases (like the one you suggested) that justify it being a json file, as not everybody out there is writing parsers and compilers, and is generally a familiar and accessible format.

from custom-elements-manifest.

but typescript should handle such cases or any ast parser I do not understand why you should want to generate metafiles for tooling when you can generate all needed info out of the source?

from custom-elements-manifest.

Ok i am also not clear i understand the need to generate react components but the way whits json between that is not clear

the ideal formart for a isomorphic component is any template engine then embed that inside a component wrapper.

from custom-elements-manifest.

The so component definition should look something like

const myComponent = (name)=>`I am a Full WebComponent my Name is ${name}` 

you can wrap this then for react vue or what ever nativ components also work well

It exposes all props in this case name

from custom-elements-manifest.

but typescript should handle such cases or any ast parser I do not understand why you should want to generate metafiles for tooling when you can generate all needed info out of the source?

Yes, that is exactly the goal. Tools like web-component-analyzer are meant to scan/parse/whatever your source code files, and then outputs a metafile (custom-elements.json), which can be useful for tooling, IDE integration, creating react wrappers, chrome extensions, documentation generation, and much more.

Please see the README for more information.

from custom-elements-manifest.

@thepassle I am for such tooling but I am against JSON files :)

i will not do a build then create write JSON then run over that JSON that is not thinkable.

from custom-elements-manifest.

you should name this custom-element parser it should search for customElement register calls then it should do whatever analyzes is needed it could be a rollup plugin.

from custom-elements-manifest.

https://marketplace.visualstudio.com/items?itemName=runem.lit-plugin does that for lit-html and customElements.

from custom-elements-manifest.

This literally is not a parser though. This repo is meant to standardize around a format that tools/IDEs/plugins etc can easily use, which in this case is JSON. The goal is to get a consensus on what exactly it should look like. The goal is not to create a parser, if that is what you want, you are free to do so.

should search for customElement register calls

There may be cases where you don't want elements to self register, yet still want to have metadata for those components for e.g. documentation generation.

it could be a rollup plugin.

Many people do not use rollup.

JSON is a widely supported format by many different tools/IDEs, and is an excellent file format for this usecase, if you disagree, you are welcome to make a separate proposal on what you think it should be. I feel like this is starting to become unfruitful discussion.

from custom-elements-manifest.

@thepassle but we got JSDOC for documentation? but ok I understand if there is a need there is one I only wonder why the community never did that before for anything else :)

I have only the fear of over-engineering and leading people in the wrong direction.

I propose to code custom-elements as ECMAScript Optional Document them via JSDOC optional type check via JSDOC and typescript.

I do not want to see that people start a JSON file documentation :) but ok I can do nothing against it I hope only that other implementors are aware of such ideas and i hope they will not adopt.

from custom-elements-manifest.

ok so the tooling can also use JSDOC Directly :)

from custom-elements-manifest.

you should maybe raise a issue for some extra filds inside JSDOC ?!?! for your documentation tooling needs?

from custom-elements-manifest.