Question: Snippets

[ghost]

I currently have a collection of VSCode snippets: s43.io/FabricSnippets in beta, meaning they don't yet cover all components and need some work to bring them up to date with the 2.1.0 release and also make true extensions for VS Code, VS, and Textmate (which will support Sublime, IIRC). I have another release to rollout in the next couple of days and am beginning to think about ways to keep these up to date with Fabric as it evolves.

So here's the question...is there any interest in adding these to the Fabric repo and having the build process handle the creation of the different versions (VS, Textmate) from the VSCode snippet? If so, I'll move in that direction. If not, I'm open to suggestions on how best to keep these current and providing value.

Thanks,

Dave

[mikewheaton]

Thanks so much for doing this – snippets for Fabric make it much easier to use and I can see them being very welcome by developers. We'll have to discuss if/how we see them fitting into the core project. And if they remain a separate project, what we can do to help you automate their generation.

[ghost]

Thanks. I'm open to whatever makes the most sense and provides the most value, knowing that in the long run one person (me, for now) almost certainly cannot keep pace with the whole Fabric community as the core project evolves. Like I said, ideas welcome. :-)

[ghost]

Any further discussion on this? I've got someone interested in providing a way to automate the conversion of the VSCode snippets to Visual Studio, which is a nice capability. I just pushed a new release of the Snippets, but need to update them to the 2.2.0 release.

Thanks.

[mikewheaton]

We haven't had a chance to discuss this yet. Do you have any suggestions for how we could make it easier for you to generate snippets from our codebase?

[ghost]

No worries, I'm just coming back up for air after finishing the PS course and some client work so I figured I would check in. I was thinking of trying to do it in a Gulp task. If I'm successful, do you think the task could be added as an option in the build process?

[mikewheaton]

We'd definitely be open to that. You would be using the HTML template files as a source, right? What about the Sass/CSS? We have some changes planned to the build process, so if you want to get a start on it we can review it early (so you don't spend too much time) and make sure that our build will continue to provide what you need.

[ghost]

OK. I'll try to get started soon and get back to you on progress. Yes, I'd be using the HTML templates files as the source, I don't see a need to touch the Sass/CSS as all the snippets do is insert the HTML in place of the trigger characters. At a high level, here's what I see the process looking like:

1. Read the source HTML from the template files for each component
2. Wrap that input with the snippet schema (VSCode/VS)
3. Write the final file to the /dist folder

Actually, now thinking about it a little more...the problem is going to be getting the right JavaScript and any embedded components or elements (for example, a CommandBar in the Panel, or table rows inside the table). Let me noodle on it for a bit and see what I can come up with and then I'll report back...

[ghost]

I can't come up with a reliable way of doing this that isn't extremely fragile without:

1. Adding some type of indicators in the HTML as comments to indicate things needed by the snippet generator, such as nested components, etc.
2. Refocusing the HTML to be less of an example of a fully working component and more of a developer focused piece of reusable code
3. Adding an additional file to the source tree that is the snippet file itself which must then be maintained.

None of those are great options, but I know I can't maintain it all myself - I'm 2 releases behind now, but hope to get caught up this week.
The problem is really when one HTML file for a component has other components within it - CommandBar inside Panel, indidual peoplepicker results inside a peoplepicker component, etc. I think I have a way to tackle everything else in a Gulp task.

Of the three options above, I think the first one would be least intrusive and easiest to maintain. I'm open to other ideas if anyone has them.

Thanks,

Dave

[mikewheaton]

Would our upcoming conversion to Handlebars templates help with this? Those templates will have {{ placeholders }} for all of the values. When a component has subcomponents those will be included into it as separate templates, not duplicated in the HTML of the parent component.

[ghost]

Hmmm...Yes, that might help. I didn't know that was happening, but good to hear. Are there samples somewhere I can take a look at?

[mikewheaton]

You can take a look at the miljo/gulp-handlebars to see some of this work in progress. For example, a Handlebars template for Button.

[mikewheaton]

Have you had a chance to look at the Handlebars samples, @manndave? We're doing a lot of work on this now to prepare for the Fabric 3.0 release. It seems that there should be a way to automate the conversion of a Handlebars template to a code snippet. Let us know if there's anything we can provide to make this easier. Once Fabric 3.0 is out we should have more time to help with this.

[ghost]

@mikewheaton: Haven't had a chance yet, probably this weekend or early next week.

Thanks.

[mikewheaton]

Closing this issue for now as there's no action on our end. Please get in touch if you want to discuss this further – we definitely want to support helpful developers tools like this!