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

fix: Add icon granularity to HTML code generation #315

Merged
merged 13 commits into from
Aug 3, 2020

Conversation

Voltra
Copy link
Contributor

@Voltra Voltra commented Jul 27, 2020

Changes

  • Make HTML codegen conditional according to granularity of icon sets
  • Refactor HTML codegen (reducing boilerplate and copy/paste issues)

Why

From #312 it has been brought to my attention that HTML codegen was not affected by the newly added granularity.
This aims to only generate HTML for icons that were specified.

How

With a few helpers, check if the options for the working icon set is an array and if it is, only generate the selected options. If it's not an array, proceed as usual.

Feedback

It modified a lot of the HTML codegen structure to allow for better maintainability and flexibility (e.g. adding new icons). This also clears a lot of "code smells" were a lot of lines were simply duplicates with small adjustments. Also brought to the light that there were a lot of strange decision regarding whitespaces (especially between HTML attributes for some reason) as well as a bad habit of not autoclosing tags (i.e. leaving them open as if they were opening tags).

You can take a look at config/html.js from line 40 to line 71, especially the href attributes and end of tags to know what I'm talking about.

Nota Bene

I will not in any way shape or form alter the tests and/or fixtures/snapshots that rely on mentioned strange decisions.
As such, some tests fail (due to missing whitespaces).

Improvements in code quality makes it trivial to implement #289 on top of it.

Voltra added 8 commits July 8, 2020 15:00
Rendering is conditional based on whether or not the icon set is using
an array, if not it returns the value of the icon set.
For instance, `icons.favicons === false` would not generate HTML for
favicons.

Also refactored a lot of repeated (copy-pasted / line duplicated) code.
Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, can we add couple tests to avoid regressions in future?

@Voltra
Copy link
Contributor Author

Voltra commented Jul 27, 2020

I will, as soon as all the test stop relying on arbitrary whitespace constraints.

@alexander-akait
Copy link
Member

@Voltra What is the next step for us?

@Voltra
Copy link
Contributor Author

Voltra commented Jul 27, 2020

Snapshots/fixtures should be rewritten to avoid the use of specific amounts of whitespace per item (only 1 per attribute). I also recommend the use of self-closing tags (i.e. <meta/> instead of <meta>). These are the cause of all failures. In an ideal scenario, tests would diff the DOM structure instead of the actual string.

Once all the whitespace issues are gone, I can proceed with tests for granularity on the HTML code generation level.

@alexander-akait
Copy link
Member

Once all the whitespace issues are gone, I can proceed with tests for granularity on the HTML code generation level.

Do you want to send a fix?

'<link rel="apple-touch-icon" sizes="167x167" href="/apple-touch-icon-167x167.png"/>',
'<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon-180x180.png"/>',
'<link rel="apple-touch-icon" sizes="1024x1024" href="/apple-touch-icon-1024x1024.png"/>',
'<meta name="apple-mobile-web-app-capable" content="yes"/>',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should avoid / here and introduce the html5 option, but we can do it in separate PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although they are considered useless as per the HTML5 standard, they still carry the meaning of being closed immediately with no content

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's avoid them anyway, I'm sure users will create a problem about this.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job! Can we merge?

@Voltra
Copy link
Contributor Author

Voltra commented Aug 3, 2020

The tests pass for the HTML generation

@alexander-akait alexander-akait merged commit aace90b into itgalaxy:master Aug 3, 2020
@alexander-akait
Copy link
Member

@Voltra What is the next?

@dmnsgn
Copy link
Contributor

dmnsgn commented Jan 28, 2021

@Voltra has the html code generation been merged and published for? Latest release seem to be "on 21 Jul 2020" so I would assume that no because you would like to fix manifest generation as well?

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

Successfully merging this pull request may close these issues.

3 participants