-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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(web): extra spaces in HTML attribute #21855
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your automatic check seems not to have included all cases.
Should we also include the other case char {{<something>}}class
in this PR, or do we open another PR for it?
If you are really sure about your regexes, you could put them below this one as a sed replacement for auto-formatting during Line 271 in 0b993a0
|
In fact I'm not very confident in my regex. I was afraid it would inadvertently destroy something. |
Need to rebase. |
Test failures do seem related, but it's not immediately clear to my why. |
In particular:
I suspect the changes have broken the url somehow. |
The above two things should fix the problem but we should really go through this PR and double check that it's doing the correct thing. |
The issue was constructed with so many files (a mind-boggling 148) that regex were my only option. My regex isn't very good, therefore it could have resulted in an incorrect alteration. I also made an effort to go back and revert any incorrect alterations, but it was simply too much. Inevitably, something is missed, and we can only rely on the keen eye of the reviewer. |
First failure on CI is odd because it's being seen outside this PR too, so I think it may be flaky/unrelated. See #21854. |
Can you get the tests to pass please? Then I'm happy to review. |
There were two more mistakenly added spaces. |
I have objection to this change, and suggest to stick to The readability and maintainability should be applied to the code which is read by developers, but not for the generated outputs. The template code is the code for developers, while the generated HTML are only for browsers. The Think about a more complex case:
The first style make it clearer to see each CSS class name with its |
I do agree with @wxiaoguang here - I know we've done a lot of work elsewhere getting rid of the extra spaces but I'm just not sure it's worth it given the confusion and potential for bugs it adds. Who is looking at the HTML anyway? We'd potentially be better off passing the output of our HTML renderer through a lightweight html parser that would minimize and remove the extra spaces instead. |
Not sure if postprocessing the HTML is worth it, it'll impact performance for neglible gain. BTW, In JS land, there is the classnames module that's used to join together class names, maybe something similar could be done for go templates as well, thought it'll never be as elegant as the JS solution. |
### The CustomEvent prefix There was already `ce-quick-submit`, the `ce-` prefix seems better than `us-`. Rename the only `us-` prefixed `us-load-context-popup` to `ce-` prefixed. ### Styles and Attributes in Go HTML Template #21855 (comment) Suggest to stick to `class="c1 {{if $var}}c2{{end}}"` The readability and maintainability should be applied to the code which is read by developers, but not for the generated outputs. The template code is the code for developers, while the generated HTML are only for browsers. The `class="c1 {{if $var}}c2{{end}}"` style is clearer for developers and more intuitive, and the generated HTML also makes browsers happy (a few spaces do not affect anything) Think about a more complex case: * `class="{{if $active}}active{{end}} menu item {{if $show}}show{{end}} {{if $warn}}warn{{end}}"` * --vs-- * `class="{{if $active}}active {{end}}menu item{{if $show}} show{{end}}{{if $warn}} warn{{end}}"` The first style make it clearer to see each CSS class name with its `{{if}}` block. Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Remove extra spaces in class attributes caused by conditional statements
Example:
When
IsLDAP
is false, will render<div class=" field">
not<div class="field">
. So should put space in conditional statements.Changes are made by VS Code regex replace and are checked manually.
class="\{\{if (.*)\{\{end\}\}
->class="{{if $1 {{end}\}
class="(.*) \{\{if (.*)\}\}(.*)\{\{end\}\}
->class="$1{{if $2}} $3{{end}}