Added possibility of extending and creating new elements

[somewebmedia]

This way users can create their own elements, or extend the current ones. See the example in the readme.

[rafibomb]

👍 This is definitely where we're going with Inky. We'll be reviewing it for merge or suggestions - thanks!

[kball]

@somewebmedia I love the direction this is going, but I'd like to push for this to move further from the details of node and the current inky approach of cheerio and string formatting, and more into something that can be compartmentalized into a package that can be used by different implementations (e.g. we're building a ruby version of inky, similarly I think we need to move away from cheerio and towards something that gives us a tree-based view of the html)

We're planning to open a discussion around this in a bit, but I'm imagining a pluggable component architecture that looks something like

1. A template (probably handlebars)
2. An scss file
3. A json file of structure:

{
  component: componentName,
  template: templateFilePath,
  scss: scssFilePath
}

What do you think? Do you have any examples of components you'd like to build that we can check and make sure this would satisfy their needs?

[somewebmedia]

@kball

I think changing to a json object spec is a great idea for a major iteration (e.g. major version bump) for the purpose of porting inky to other languages. However, porting this library to other languages seems like a large amount of work that is not specifically related to adding the ability for current users of inky to make their own components. This approach is 100% compatible with the current version so users can drop this in without having to concern themselves with a breaking change.

This will be very helpful to me and likely other current users. The json manifest approach is a big change and it sounds like there are decisions that still need to be made (ex: should you use handlebars or another DSL).

Would you be ok merging this now and taking the refactor as future work?

[rafibomb]

@somewebmedia Just published the Foundation for Emails 2.1 release blog post and the release went out this morning! We also started a discussion on the future of Inky and what amazing integrations can be made. I'm sure you have some comments, questions, or ideas: http://foundation.zurb.com/forum/posts/39717-architecting-the-future-of-foundation-for-emails

[rafibomb]

@somewebmedia @kball Just checking in on this! Love the idea and progress so far! What is left to be done to move this toward completion?

[alexisgahon]

Any update on this PR ?

[ahebrank]

This would have been a much more elegant, client-friendly solution that what I ended up doing, which was a Handlebars partial to inject some markup. I agree with @somewebmedia that an incremental, non-breaking improvement now is far better than a big refactor... someday.

[SharpeRAD]

Any reason why this PR hasn't been accepted? I understand you may want to change the direction of inky in the future but in the meantime this looks like a great way of adding extensibility to the project NOW 👍

[rickysullivan]

DED

[JimmyMultani]

Hey @rafibomb, any idea on when this will be merged? Are we waiting on @somewebmedia to update the pull request with something?

Thanks!

[DanielRuf]

There are currently conflicts which have to be resolved.

[somewebmedia]

I'm not using this project for a long time now. Someone should fork my code and resolve the conflicts if you want this changes to be implemented.