-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
ui: dashboard links #5704
ui: dashboard links #5704
Conversation
353705f
to
0cf1317
Compare
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.
@johncowen nice! I might just be not understanding things as my Ember fu is weak but some questions inline
}; | ||
const weak = createWeak(); | ||
|
||
const templateRe = /{{([A-Za-z.]*)}}/g; |
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.
Do you need to escape {
and }
in JS regexp? I guess not if this works just wondering if it's one of those things where not escaping seems to work but accidentally matches other stuff like how foo.com
matches fooZcom
? Other examples I've seen of handlebars syntax regexp in JS do escape the opening ones at least?
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.
Not that I'm aware of, it's potentially one of those 'optional' escapes that eslint warns you that it's not needed, will take a look though. First glance its looks like \{
and {
both match the same thing.
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.
Ok so, if I've understood correctly, generally you do not need to escape {
s unless it's part of a repetition operator (like {1,3}
) - but you can if you want. I think I'll put some comments above this at least though. I usually do that with RegExp to make them super clear.
Actually, the more I look at this the more I wonder, I should probably switch the *
to a +
. Plus, do you know whether we are allowing people to use meta data for interpolation, I was trying to keep the matches pretty restrictive just for our API keys but maybe I should add 0-9
and _-
in there?
Key can contain only ASCII chars and no special characters (A-Z a-z 0-9 _ and -)
https://www.consul.io/docs/agent/services.html
What do you think?
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.
Restrictive is great... see reply in main conversation.
.trim(), | ||
'template block text' | ||
); | ||
}); |
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 could be missing something but it looks like this doesn't actually test the variable replacement? Do we know that regexp etc. works?
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.
So these are just the auto generated tests when you use an ember generator to create your stubs. They generally just test the thing you generate can be instantiated.
I've added some integration tests with some basic usecases which cover the regex.
Hey! So I remembered the talk we had last week where we discussed this, and I vaguely remember we briefly discussed being able to use meta keys for interpolation here, so I added those extra characters in as well as adding some basic testing around usage. |
Thanks @johncowen,
I guess this highlights the risk of working on even simple features that weren't well documented just discussed verbally. The intent of this feature is that we only support interpolating a very small handfull of values from the current context in the UI:
The whole idea of templating these on the front end came from the original plan that these would be configured centrally (i.e. UI fetches them separately from the service instances themselves). In moving to pulling the url template from service meta, it basically doesn't make any sense to have this templating done in the UI any more... Consul servers also have all the context the UI does at this point and could just resolve the template themselves in the API which is way more useful. I'm going to think about this a little more and we can talk about it tomorrow. |
Hey Paul! Thanks for reviewing this, looks like you caught a biggie there! 😅 Yeah for sure, with the talk of being able to interpolate meta data and the suggestion of Don't worry though, if you are going to do all the above in the backend (template interpolation etc), the above PR should still 'work fine' (and I learnt why I don't have to escape
I'm not sure if you are still going with the plan of these strings for interpolation (do we use these values anywhere else), but if you are set on these, then we should probably at least think about making the
Cool, gimme a yell when you are about, but we should probably get something written down that you are happy with first so we aren't just discussing these things verbally again! |
1. Removes dashboard button from node detail and service instance detail pages 2. Adds very basic settings page to enable input of templatable url 3. Uses new localStorage based template for url interpolation
2e6f520
to
d8d21c6
Compare
This pulls in some select details from new design work so that the settings page looks repsectable. Potentially this could clash with another currently open PR. Both this commit and the commits in the other PR look fine on their own, but once merged they 'may' clash somewhere. Decided it was best to add these changes to this PR rather than the other as these changes are a direct result of needing to add new things into the Settings page
This is ready to go again, I also added some screengrabs to the PR description |
Looks like Ember tests are failing here ^ |
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.
Just needs CI to pass but otherwise LGTM
Cool, missed a little dependency for a unit test, thanks for spotting! Test are passing again now |
This PR adds a new {{template-anchor}} component. This component lets you specify a 'href template' in a handlebars like format instead of a normal string href. This template will be interpolated with the contents of a vars="" attribute. Also contains code to add an extra UI Setting to be able to store a template to be used for this anchor in localStorage
This PR adds a new
{{template-anchor}}
component. This component lets you specify a 'href template' in a handlebars like format instead of a normal string href. This template will be interpolated with the contents of avars=""
attribute.href
s are currently purposefully left blank.href
s use theconsul-dashboard-url
meta value.href
s use a UI Setting that you can add on a per user basis via the UI Settings page (see grabs below)Screens currently use the current styling/widgets - these will be updated across the UI as a whole 🔜
Settings page:
Dashboard link: