* ui: Add more explanatory texts for empty states
* Change all template "Read the guide"s
* Add missing htmlSafe
* Remove the stuff I commented out to try and grok the hairy rebase
* Changelog
* More rebased yaml weirdness plus added node:read
This commit moves our in-app LockSessions code into an external 'app', which can theoretically be side-loaded but for now it just makes for good isolation/code hygiene.
Functionally, there is kind of one change here, and that is we only show the 'Lock Session' tab if you have permissions to see them. Currently as our UI authorization endpoint needs to be changed slightly to suit our usecase, you will always have permissions to see Lock Sessions as we hardcode the session:read to true (obvs this is a frontend thing, not a backend thing), so it doesn't really change anything from a user perspective.
Also added very bare docs while I was here.
Small note here, ideally we need to add the each individual tab depending on whether an 'app' is enabled or not instead of just permissions, ideally it would be done totally from The Outside rather than a can based conditional on the inside, just something else to be thinking about for the future.
This PR adds an Ember-Glimmer/Handlebars transform to drop the documentation copy from the CustomElement component out of the build, therefore it is not bundled into the code either at development time or production build time.
Builds on attach-shadow, adopt-styles and ShadowTemplate, this commit adds ShadowHost and finally CustomElement.
CustomElement is a renderless component to help with the creation of native HTML Custom Elements along with runtime type checking and self-documentation for attributes, slots, cssprops and cssparts. As you will probably see there is a little more work to come here. But in the same breath, everything would be fine to go in as is.
This adds a new component blueprint for all our components. We've been
using README.mdx files for quite some time to document our components
for other engineers. This adds a default file to help new engineers get
started writing useful documentation. These README.mdx file are also
very useful for building out components in isolation from scratch and
and some point will be used to run automated component testing.
* Add %panel CSS component
* Deprecate old menu-panel component
* Various smallish tweaks to disclosure-menu
* Move all menus in the app chrome to use new DisclosureMenu
* Follow up CSS to move all app chrome menus to new components
* Don't prevent default any events from anchors
* Add a tick to click steps
* Delete collapsible notices component and related helper
* Add relative t action/helper to our Route component
* Replace single use CollapsibleNotices with multi-use Disclosure
This commit excludes the health of any service instances from the Node Listing page. This means that if you are viewing the Node listing page you will only see failing nodes if there are any Node Checks failing, Service Instance Health checks are no longer taken into account.
Co-authored-by: Jamie White <jamie@jgwhite.co.uk>
We noticed that the Service Instance listing on both Node and Service views where not taking into account proxy instance health. This fixes that up so that the small health check information in each Service Instance row includes the proxy instances health checks when displaying Service Instance health (afterall if the proxy instance is unhealthy then so is the service instance that it should be proxying)
* Refactor Consul::InstanceChecks with docs
* Add to-hash helper, which will return an object keyed by a prop
* Stop using/relying on ember-data type things, just use a hash lookup
* For the moment add an equivalent "just give me proxies" model prop
* Start stitching things together, this one requires an extra HTTP request
..previously we weren't even requesting proxies instances here
* Finish up the stitching
* Document Consul::ServiceInstance::List while I'm here
* Fix up navigation mocks Name > Service
We need a way to load certain CSS based on the environment you are viewing, i.e. we have debug CSS that we use for our Eng Documentation and various other DX utilities that shouldn't be compiled into our production or test builds.
Previously we would compile two entirely different CSS files (app and debug) and the load one or the other depending on which environment you were in.
This approach just empties out the debug.css file in certain environments (prod/test) which means we can just import that file from app. When in staging/development this imports the contents of debug.css (quite a bit of CSS) whereas when building for production/test this debug.css is emptied out during the build process.
There is a slight little hack in order to have this work, we import _debug.scss which imports the debug.scss file. I couldn't for the life of me figure out how to have broccoli empty out a file during the build process, so instead we essentially copy over debug.scss during dev and create an empty file during prod to _debug.scss.
When using make build to build an artifact for production CSS remains at ~58kb (during dev its a lot bigger than this)
{{class-map}} is used to easily add a list of classes, conditionally, and
have them all formatted nicely ready to be printed in a DOM class attribute.
For ease, as well as using entries, you can also just provide a simple string
without the boolean and that class will always be added.
* ui: Correct some meta info
* Encoder doesn't take an argument whereas decoder does
* Math.trunc looks like the closest to parseInt but using the correct type
* use a dynamic string when setting things on window
- Simplifies how we 'import' our configuration files a little in order to make them more grokable.
- Starts to exclude files based on explicit configuration rather than convention.
- Adds the first instance of us being able to select an implementation (of multiple) of a component at runtime.
The fix here is two fold:
- We shouldn't be providing the DataSource (which loads the data) with an id when we are creating from within a folder (in the buggy code we are providing the parentKey of the new KV you are creating)
- Being able to provide an empty id to the DataSource/KV repository and that repository responding with a newly created object is more towards the "new way of doing forms", therefore the corresponding code to return a newly created ember-data object. As we changed the actual bug in point 1 here, we need to make sure the repository responds with an empty object when the request id is empty.
John Cowen