Closed SamMousa closed 6 months ago
@josdejong rudely pinging you!
This PR solves the styling issue:
--jse-svelte-select
prefix. I hope you like it, otherwise I wasted a few hours for nothing xD
Thanks a lot Sam, it looks neat at first sight! I'll do an in-depth review+testing coming Wednesday I expect.
One first thought: I think the file jse-theme-dark.css
should not contain SCSS variables and be plain CSS, so I think $text-color
should remain var(--jse-text-color)
like it was before?
Yes, that might be a global search and replace mistake. Thought I caught all of them..
I see there where some tricky things involved, like getting the colors work in text mode, and you did something nice with the calculation of the left margin of nested items. Great job!
This is a lot more work than the original 1 line PR π , but I really love how this works out. It is indeed easy to maintain like this.
I've gone through all details of the editor, and almost everything looks alright! I came across a number of (I think) small issues, listed below. Can you have a look into those? Please let me know if you need help.
I've mostly tested with the development page http://localhost:5173/development:
Using the default theme:
text
mode are red instead of blackUsing theme "dark":
text
mode are light green instead of light blue (same issue as default theme?)Using theme "big"
I've fixed some points, others remain open; I'd love some help to pull this over the finish line.
Regarding the buttons in modals I think the way this is currently implemented should actually be configured a bug:
--jse-theme-color
sets the primary theme color at the top level--jse-modal-theme-color
sets the primary theme color for use inside modals--jse-button-primary-background
is defined as var(--jse-theme-color
Due to the way CSS variables work the variable defined in 3 has the value from 1, even if it is shown inside a modal. This seems to be a reasoning error. Inside a model you have redefined the primary theme color so the button should obey that. This screenshot from jsoneditoronline.org shows the inconsistency with respect to the menu bar, which also by default has the theme color.
Thanks for all the fixes. I'll look into the issue with the modals, no problem.
Big tip: if you see $variable
in developer tools it's an issue with SCSS escaping. On the right hand side of CSS variable declaration SCSS requires explicit interpolation: --jse-abc: #{$abc}
instead of the default implicit interpolation: background-color: $abc;
Regarding the buttons in modals I think the way this is currently implemented should actually be configured a bug
Your explanation is correct. However my intention was a bit different: I wanted to be able to just give the menu of the editor inside a modal a different color because it was looking ugly to me. So I think the name --jse-modal-theme-color
is misleading and should be something like --jse-modal-editor-menu-background-color
. Renaming would be a breaking change, but we can keep it backward compatible I think. Does that make sense?
I wouldn't worry about BC at this level of detail to be honest. I mean anything can be considered a BC break if you're critical enough.
This PR already breaks BC because we no longer support overriding some specific svelte-select settings via the original CSS variables, you have to use the --jse-svelte-select
prefixed version for some of them.
Good point, it's already a very breaking change π . I'll publish it as a major release and explain the changes.
While you're at it you could also document the BC promise.
For example you could say that users customizing svelte-select
should ALSO use the prefixed variables. This allows you to customize those properties in the future without it being another BC break.
Just for clarity: do you want me to finish the last open issues?
Just for clarity: do you want me to finish the last open issues?
yes please!
okido
I created https://github.com/josdejong/svelte-jsoneditor/pull/350, fixing the last open issues. I want to do one more testing round later this week, I expect on Wednesday.
@SamMousa one last question: do you know whether the new way to handle indentation with a CSS variable --level
has any performance implications? I'm a bit in doubt whether CSS variables are suitable to be used like this, with possibly thousands of re-definitions with every re-render.
I can't imagine it is faster to change styles directly, since you're doing 1000s of updates in such a case as well... But this is a guess
I just did a small test by hand, it actually feels a bit faster π. I didn't do a real benchmark but it is as fast as before or a bit faster.
That's what I expected, in theory it is more optimizable:
It makes sense indeed. This is a nice side-effect of this refactor ππ
Btw, for future reference: you can directly push to a PR branch as well, as long as a contributor has checked the checkbox during pr creation. Thanks for your efforts in finishing it!
Ahh, I didn't know that. That's very handy indeed, also for example for PR's that are about finished but just have a linting error or something like that.
Btw, for future reference: you can directly push to a PR branch as well, as long as a contributor has checked the checkbox during pr creation.
Yay, that indeed works π
I've done another testing round, found a few small things and cleaned up some left over TODO's.
Time to merge this PR.
The refactoring is now published in v0.20.0
. Thanks a lot for all your effort and for thinking along Sam!
This reworks the default theme to use SCSS variables.
defaults.scss
file.Some things that are still todo:
getIndentationStyle()
inCollapsedItems.svelte
getIndentationStyle()
inJSONNode.svelte
Since these todos only require a very small subset of variables one solution is to define them in the relevant component as internal CSS variables.
Todo from feedback below: Using the default theme:
the selection bar between two rows:
Using theme "dark":
In the nested editor modal (same as with the default theme I think):
Using theme "big"