Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Allow to configure some options of the profiler interface #27678

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

Merged
merged 1 commit into from
Jul 18, 2018

Conversation

javiereguiluz
Copy link
Member

Q A
Branch? master
Bug fix? yno
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets -
License MIT
Doc PR -

This PR adds some configurable options for the interface of the Symfony profiler.

First, you can configure the theme. The current one remains as the default light theme, but there's a new dark theme. A quick comparison:

theme-light

theme-dark

The second option is the width of the profiler pages. The current normal width remains as the default, but there's a new dynamic width that is as width as the browser window. The "Performance" panel is the one where this option makes more sense. A quick comparison when using a 2560 x 1440 resolution:

settings-width-normal

settings-width-wide

All settings are managed by JavaScript and persisted in localStorage, so everything is fast and simple:

settings-in-action


Note to reviewers:

  • This is the first draft of the PR.
  • I expect: approval/rejection of this idea and general comments of the proposed solution.

Once this is accepted, I will finish the feature tweaking/fixing the design and the HTML/CSS/JS/Twig code. Don't comment on those details for now. Thanks!

@nicolas-grekas
Copy link
Member

IE 11 doesn't handle CSS var() - not a blocker, just worth noting.

@wouterj
Copy link
Member

wouterj commented Jun 22, 2018

This however does mean we have to keep the existing styles, to have a fallback color for non-supporting browsers

@javiereguiluz
Copy link
Member Author

@wouterj in the past we've made similar decisions (for example when we switched to using Flexbox in some parts of the profiler). Probably all of our developers use a compatible browser (https://caniuse.com/#feat=css-variables).

@stof
Copy link
Member

stof commented Jun 22, 2018

@nicolas-grekas for the webprofiler UI itself, I'm fine if it does not work in IE 11. Devs will hopefully still have a modern browser where the can open the profiler (the WDT is a different topic, as that's injecting in the page so being incompatible would hurt the dev debugging their own page in IE)

@@ -647,7 +686,7 @@ tr.status-warning td {
#menu-profiler li a {
border: solid transparent;
border-width: 2px 0;
color: #CCC;
color: var(--base-3);
Copy link
Member

Choose a reason for hiding this comment

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

should it use the variable if it does not change based on the theme ?

}

.modal-wrap {
-webkit-transition: all 0.3s ease-in-out;
Copy link
Member

Choose a reason for hiding this comment

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

IMO, you can drop the vendor prefix here. All modern browsers support it unprefixed (and otherwise, it should still stay just before the unprefixed property IMO).

}
</style>

<a href="#" id="open-settings" data-triger="profiler-settings">Settings</a>
Copy link
Member

Choose a reason for hiding this comment

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

semantically, this should be a <button type="button">, not a link (not sure our profiler UI is accessible yet though)

</div>

<script>
let configOptions = document.querySelectorAll('.config-option');
Copy link
Member

Choose a reason for hiding this comment

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

this is leaking tons of global variables in the page. Please wrap it in a function.

Copy link
Contributor

@apfelbox apfelbox Jun 23, 2018

Choose a reason for hiding this comment

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

let doesn't leak in the global (window) scope. See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let

At the top level of programs and functions, let, unlike var, does not create a property on the global object.

(However, I would still wrap it, just to be safe of accidental var usage and some other issues.)

let configOptions = document.querySelectorAll('.config-option');
let oppositeValues = { 'light': 'dark', 'dark': 'light', 'normal': 'wide', 'wide': 'normal' };
[...configOptions].forEach(option => {
option.addEventListener('click', function (event) {
Copy link
Member

Choose a reason for hiding this comment

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

you should rely on the change event. I'm not sure changes performed using the keyboard are triggering click events.

--table-background: #fff;
--table-header: #e0e0e0;
--shadow: 0px 0px 1px rgba(128, 128, 128, .2);
--border: 1px solid #e0e0e0;
Copy link
Member

Choose a reason for hiding this comment

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

should we have the whole border as a variable or only the color ?

Copy link
Member

Choose a reason for hiding this comment

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

same for the shadow btw

--page-background: #36393e;
--table-border: #444;
--table-background: #333;
--table-header: #555;
Copy link
Member

Choose a reason for hiding this comment

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

--table-border and --table-header are the same color in light theme (as well as the color used by --border), but they are different in dark mode. Is it expected ?

@stof
Copy link
Member

stof commented Jun 22, 2018

Having the dark theme switch as easy as that is great IMO. The maintenance cost of the feature is very low, so +1 from me on the idea.

@stof
Copy link
Member

stof commented Jun 22, 2018

Regarding the wide mode, #25761 had a few rules to avoid some elements becoming too wide. Do we need them here ?

</div>

<div class="modal-footer">
<button class="btn close-modal">Save changes</button>
Copy link
Member

Choose a reason for hiding this comment

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

the wording save change is confusing IMO. Even if you don't click this button (closing the profiler tab for instance), the changes are still persisted, as they are saved immediately, not when clicking this button.

@jkufner
Copy link

jkufner commented Jun 22, 2018

The "Wide" option does not make much sense. Elements which are meant to be wide, like tables or plots, should be always wide. Other elements should keep some reasonable width anyway.

Simple wide/not-wide switch will cause some elements to be too narrow or some to be too wide. It won't be perfect either way. Please take a look at CSS rules in #25761; they set optimal width to most elements (not perfect yet — few more rules may be required, but close enough).

@javiereguiluz
Copy link
Member Author

@jkufner I won't repeat the arguments given in the #25761 discussion ... but some people wanted to have a full-page width profiler, so that's what we're giving them here. I consider confusing to provide an "hybrid mode" where some elements are normal and others wide.

@javiereguiluz javiereguiluz changed the title Allow to configure some options of the profiler interface [WIP] Allow to configure some options of the profiler interface Jun 22, 2018
@ro0NL
Copy link
Contributor

ro0NL commented Jun 23, 2018

in dark mode the grey scale of the menu looks off IMHO

@javiereguiluz
Copy link
Member Author

I've made a lot of change according to the first comments. This is now ready to start reviewing all the details about design and code. Thanks!

@fabpot fabpot changed the title [WIP] Allow to configure some options of the profiler interface Allow to configure some options of the profiler interface Jul 13, 2018
@fabpot fabpot force-pushed the profiler_settings branch from bbaf964 to 944c53f Compare July 18, 2018 12:37
@fabpot
Copy link
Member

fabpot commented Jul 18, 2018

Thank you @javiereguiluz.

@fabpot fabpot merged commit 944c53f into symfony:master Jul 18, 2018
fabpot added a commit that referenced this pull request Jul 18, 2018
…ace (javiereguiluz)

This PR was squashed before being merged into the 4.2-dev branch (closes #27678).

Discussion
----------

Allow to configure some options of the profiler interface

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | yno
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

This PR adds some configurable options for the interface of the Symfony profiler.

First, you can configure the theme. The current one remains as the default light theme, but there's a new dark theme. A quick comparison:

![theme-light](https://user-images.githubusercontent.com/73419/41765883-ad2f9e6a-7605-11e8-87fb-881afbffc788.png)

![theme-dark](https://user-images.githubusercontent.com/73419/41765888-af597800-7605-11e8-9097-eb9667b82136.png)

The second option is the width of the profiler pages. The current normal width remains as the default, but there's a new dynamic width that is as width as the browser window. The "Performance" panel is the one where this option makes more sense. A quick comparison when using a 2560 x 1440 resolution:

![settings-width-normal](https://user-images.githubusercontent.com/73419/41765890-b4affe14-7605-11e8-80b9-99ca54b07b83.png)

![settings-width-wide](https://user-images.githubusercontent.com/73419/41765891-b6506876-7605-11e8-95c4-664b1fb0f3dd.png)

All settings are managed by JavaScript and persisted in localStorage, so everything is fast and simple:

![settings-in-action](https://user-images.githubusercontent.com/73419/41765926-ce04f31a-7605-11e8-93f4-a7f810f034a5.gif)

-----

Note to reviewers:

* This is the first draft of the PR.
* I expect: approval/rejection of this idea and general comments of the proposed solution.

Once this is accepted, I will finish the feature tweaking/fixing the design and the HTML/CSS/JS/Twig code. Don't comment on those details for now. Thanks!

Commits
-------

944c53f Allow to configure some options of the profiler interface
@nicolas-grekas nicolas-grekas modified the milestones: next, 4.2 Nov 1, 2018
@fabpot fabpot mentioned this pull request Nov 3, 2018
@fabpot fabpot mentioned this pull request Nov 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants