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

[feature]: html as an array #190

Open
hefler opened this issue Feb 3, 2023 · 4 comments
Open

[feature]: html as an array #190

hefler opened this issue Feb 3, 2023 · 4 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@hefler
Copy link

hefler commented Feb 3, 2023

First of all, thanks for this great library!

I'm using this lib to generate multiple images in a project that happens to use liquidjs instead of handlebarsjs. Since issue #47 is ongoing, I'd like to suggest that the html property to also accept arrays, like it already does for content. In this case one could render the HTML using a rendering engine of his/hers liking yet generating multiple images.

On a personal note I'd love to have an htmlRender property which could deal with any specific template render engine. It also could be a way for gracefully deprecate any handlerbarsjs options without introducing breaking changes.

@frinyvonnick
Copy link
Owner

Hi @hefler 👋 Thx for opening this issue. Could you provide some concrete examples of usage so I could better understand your idea please?

@hefler
Copy link
Author

hefler commented Feb 3, 2023

I'll use the example from the README#Genrating Multiple Images as a base.

const liquidjsHTML = liquidjsRenderFunction( 'template.liquid', objectWithSomeData ); //outputs an HTML
const pugHTML = pugsRenderFunction( 'template.pug'', objectWithSomeData ); //outputs an HTML
const preRenderedHTMLs = [ liquidjsHTML, pugHTML ];

nodeHtmlToImage({
  html: preRenderedHTMLs,
  content: [{ output: './image1.png' }, { output: './image2.png' }]
})
  .then(() => console.log('The images were created successfully!'))

Does that makes sense?

Also might be worth to mention that in my case the same template has the logic to generate multiple different images. The only reason I'm not using content is because the template engined has to be liquidjs and not handlebarsjs. It can see it having a "workaround" feel to it. 😏 Perhaps the solution lies on issue 47?

✌️

@frinyvonnick
Copy link
Owner

@hefler I am somewhat divided over this issue. Your solution make node-html-to-image compatible with every template engine. On the other hand for my own usage I like that node-html-to-image supports directly handlebars. If we keep both there are two ways of using the library 🤔 I feels like there is a choice to make. Another solution would be to add support for liquidjs in node-html-to-image and introduce an option templateEngine.

What do you think?

@frinyvonnick frinyvonnick added enhancement New feature or request question Further information is requested labels Aug 5, 2023
@hefler
Copy link
Author

hefler commented Aug 15, 2023

@frinyvonnick Re-reading the issue made me question the quality of my writing. 😅
I think I mixed up two different features in one issue.

  1. The original issue was to request for the html prop to accept an array of multiples HTML content.
  2. The second part was to be able to allow a custom template engine.

Regarding item 1, I think it'd be nice to have multiple input sources (multiple HTMLs). It'd be needed to rethink a bit how the library would deal with the pairs html and content. Should they always have same length? Or should it generate an image for each output on each html index?

const html1 = '<html><body>I’m {{ name }}</body></html>';
const html2 =  '<html><body>My name is: {{ name }}</body></html>';
const htmls = [ html1, html2 ];

nodeHtmlToImage({
  html: htmls,
  content: [{ output: './image1.png' }, { output: './image2.png' }]
})
  .then(() => console.log('Images created'))
// OUTPUTS: 
//     image1_html1.png
//     image2_html2.png
// OR
//     image1_html1.png
//     image1_html2.png
//     image2_html1.png
//     image2_html2.png

As for item 2, Introducing templateEngine is, in my view, smart. It would allow anyone to use their own template engine. Personally, I'd also prefer the library to be agnostic of template engine and let users implement whatever they prefer, without bloating it with dependencies. But that's my personal preference, and I have no hard feelings if someone prefers something else.

Apologies if things got a bit convoluted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants