-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
updating markdown options panel to EUI #18580
Conversation
💔 Build Failed |
💔 Build Failed |
@ppisljar Are the three buttons above the settings a global component or are they manually added to each viz editor? |
@ppisljar Overall this is looking better. I found a few bugs and can offer a few suggestions for layout. First, the bugs1. Font size slider's initial state is wrongWhen loading this screen the slider's handle is always on the far right no matter the actual font-size value.
2. Links in new tab switch doesn't take effect until after you refresh the page3. When resizing the two panes, it will update the preview without having to press the update buttonThis seems like unexpected behavior to me as I feel like the only thing that should allow updating is the auto-update or update buttons. 4. Starting around 991px wide window size and below, we completely lose the preview5. Adjusting the size of the textarea can mess up the pane sizing and cover up the preview6. The help link is missingHowever, the current help link is incorrect as it just goes to Github help and not markdown help. My suggestion is to change the textarea label text to "Content" and add the following link to the far right of the label.
Layout7. If I could have my way 😁 I'd like to set up the layout like this:Both the settings and preview are in a panel and the settings panel has the scrollbar. It also overrides some background colors and pushes the floating toggle buttons into the resizing area to maximize space and minimize overlapping. |
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.
One more thing I saw there is a console error about supplying the rows property to the textarea as a string vs number.
thanks a lot for your feedback @cchaos i will work on this today and try to move it forward, but in general i will try to keep the scope of this:
ps: yes, the 3 buttons are the global editor. as well as panel resizing and floating toggle buttons. maybe it would make sense to approach this from other direction and first EUIfy the editor (so everything around the actual option panels) ? |
fixed:
not fixed:
no design changes were made to anything but the actual option panel of markdown editor |
💔 Build Failed |
Understandable about the scope issue for this PR. I'll leave it up to you in which order is best to progress with EUI-fying. I really like your solution to the textarea sizing 🥇 The one other thing I'd really like to do is put the syntax link inline with the textarea label. This way it's always connected to the input (where they're actually writing the markup) in case more options are added in between. I'd use |
💔 Build Failed |
My suggestions regarding that PR:
Besides those two suggestions, the general approach and look and feel looks good for me. Would rather have some decision on those two points before approving the PR :) |
I'm fine with removing the large "Markdown" header. I agree that it is just taking up space. I'm not sure we needs to add tabs to just to add a heading and especially if there will only be one tab. My one concern about removing it, though maybe we just move it to the textarea label ("Markdown content" or something), is that I was hoping that when we re-do the viz selector, we can change the "Markdown" option to just "Text". The reason being that, since we are now gearing Kibana towards non-engineer users, most people won't know what "Markdown" is, but if they see the option for "Text" they'll know what that is. As for you second bullet, I responded to your original about the |
I would be fine renaming the Markdown component to Text already, that would be an easy rename. Regarding the adding one tab. Peter and I also discussed the possibility of splitting things up into two tabs, so we would have one tab "Text" or "Template" with just the input box available (and the help link) and a second tab "Options" to properly split the options, like we do in all other visualizations. In my opinion it was kind of an mistake we just plugged them all in that one tab. Do you think that would be a viable solution? |
541d573
to
cd16f21
Compare
💔 Build Failed |
Could you rebase on master to get rid of some of the test failures? |
<EuiPanel | ||
grow={false} | ||
className="editorOptionsGroup__panel" | ||
className={`editorOptionsGroup__panel ${props.className}`} |
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.
This would write editorOptionsGroup__panel undefined
to the class if the property hasn't been specified. We usually use classnames for concatenating (and conditionally) apply classnames.
import className from 'classnames';
const panelClass = className('editorOptionsGroup__panel', props.className);
return <EuiPanel className={panelClass} />;
@@ -18,10 +20,10 @@ import { | |||
* to produce an aligned look and feel. | |||
*/ | |||
function EditorOptionsGroup(props) { | |||
return ( | |||
const collapsibleOptionGroup = ( | |||
<EuiPanel | |||
grow={false} |
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.
I think we want to use prop.grow
here too :-)
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.
grow on panel with accordion doesn't make any sense as accordion does not grow
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.
In that case I would add the following to the propType definition of grow
: "Only applies when collapsible
is set to false
."
</EuiFlexItem> | ||
</EuiFlexGroup> | ||
|
||
<EuiSpacer size="m"/> |
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.
Panel layouts it's content different than accordion. Looking in the rendered result, I would suggest that we remove the EuiSpacer
in this case, since it would introduce noticeable more spacing than the EuiAccordion
variant would have.
const params = this.props.scope.vis.params; | ||
|
||
const markdownLabel = ( | ||
<EuiLink className="markdown-vis--help" href="https://www.markdownguide.org/cheat-sheet" target="_blank"> |
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.
I think the class name can be removed. It doesn't seem to be used anywhere.
|
||
.markdown-vis-editor textarea { |
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.
We could instead of needing the nested query, just using className
to apply a class name to the EuiTextArea
instead.
788bbea
to
afad250
Compare
💔 Build Failed |
💚 Build Succeeded |
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.
Add some tests and that LGTM
So this is also blocked by elastic/eui#805 |
💔 Build Failed |
closing, as the bug in eui will not be fixed and we will not be euifying our editor for now |
TODO: