2019-01-25 12:30:51 +00:00
|
|
|
import Service, { inject as service } from '@ember/service';
|
2020-07-07 18:58:46 +00:00
|
|
|
import { get } from '@ember/object';
|
|
|
|
import { next } from '@ember/runloop';
|
2019-01-25 12:30:51 +00:00
|
|
|
|
2020-05-05 16:29:35 +00:00
|
|
|
import { CACHE_CONTROL, CONTENT_TYPE } from 'consul-ui/utils/http/headers';
|
ui: Adds Partitions to the HTTP layer (#10447)
This PR mainly adds partition to our HTTP adapter. Additionally and perhaps most importantly, we've also taken the opportunity to move our 'conditional namespaces' deeper into the app.
The reason for doing this was, we like that namespaces should be thought of as required instead of conditional, 'special' things and would like the same thinking to be applied to partitions.
Now, instead of using code throughout the app throughout the adapters to add/remove namespaces or partitions depending on whether they are enabled or not. As a UI engineer you just pretend that namespaces and partitions are always enabled, and we remove them for you deeper in the app, out of the way of you forgetting to treat these properties as a special case.
Notes:
Added a PartitionAbility while we were there (not used as yet)
Started to remove the CONSTANT variables we had just for property names. I prefer that our adapters are as readable and straightforwards as possible, it just looks like HTTP.
We'll probably remove our formatDatacenter method we use also at some point, it was mainly too make it look the same as our previous formatNspace, but now we don't have that, it instead now looks different!
We enable parsing of partition in the UIs URL, but this is feature flagged so still does nothing just yet.
All of the test changes were related to the fact that we were treating client.url as a function rather than a method, and now that we reference this in client.url (etc) it needs binding to client.
2021-09-15 17:09:55 +00:00
|
|
|
import {
|
|
|
|
HEADERS_TOKEN as CONSUL_TOKEN,
|
|
|
|
HEADERS_NAMESPACE as CONSUL_NAMESPACE,
|
|
|
|
HEADERS_DATACENTER as CONSUL_DATACENTER,
|
|
|
|
} from 'consul-ui/utils/http/consul';
|
2020-05-05 16:29:35 +00:00
|
|
|
|
2020-07-07 18:58:46 +00:00
|
|
|
import createURL from 'consul-ui/utils/http/create-url';
|
|
|
|
import createHeaders from 'consul-ui/utils/http/create-headers';
|
|
|
|
import createQueryParams from 'consul-ui/utils/http/create-query-params';
|
2019-01-25 12:30:51 +00:00
|
|
|
|
2020-02-18 16:43:52 +00:00
|
|
|
// reopen EventSources if a user changes tab
|
|
|
|
export const restartWhenAvailable = function(client) {
|
|
|
|
return function(e) {
|
|
|
|
// setup the aborted connection restarting
|
|
|
|
// this should happen here to avoid cache deletion
|
|
|
|
const status = get(e, 'errors.firstObject.status');
|
2020-08-11 17:47:15 +00:00
|
|
|
// TODO: Reconsider a proper custom HTTP code
|
|
|
|
// -1 is a UI only error code for 'user switched tab'
|
|
|
|
if (status === '-1') {
|
2020-02-18 16:43:52 +00:00
|
|
|
// Any '0' errors (abort) should possibly try again, depending upon the circumstances
|
|
|
|
// whenAvailable returns a Promise that resolves when the client is available
|
|
|
|
// again
|
|
|
|
return client.whenAvailable(e);
|
|
|
|
}
|
|
|
|
throw e;
|
|
|
|
};
|
|
|
|
};
|
ui: Adds Partitions to the HTTP layer (#10447)
This PR mainly adds partition to our HTTP adapter. Additionally and perhaps most importantly, we've also taken the opportunity to move our 'conditional namespaces' deeper into the app.
The reason for doing this was, we like that namespaces should be thought of as required instead of conditional, 'special' things and would like the same thinking to be applied to partitions.
Now, instead of using code throughout the app throughout the adapters to add/remove namespaces or partitions depending on whether they are enabled or not. As a UI engineer you just pretend that namespaces and partitions are always enabled, and we remove them for you deeper in the app, out of the way of you forgetting to treat these properties as a special case.
Notes:
Added a PartitionAbility while we were there (not used as yet)
Started to remove the CONSTANT variables we had just for property names. I prefer that our adapters are as readable and straightforwards as possible, it just looks like HTTP.
We'll probably remove our formatDatacenter method we use also at some point, it was mainly too make it look the same as our previous formatNspace, but now we don't have that, it instead now looks different!
We enable parsing of partition in the UIs URL, but this is feature flagged so still does nothing just yet.
All of the test changes were related to the fact that we were treating client.url as a function rather than a method, and now that we reference this in client.url (etc) it needs binding to client.
2021-09-15 17:09:55 +00:00
|
|
|
const QueryParams = {
|
|
|
|
stringify: createQueryParams(encodeURIComponent),
|
|
|
|
};
|
2020-07-07 18:58:46 +00:00
|
|
|
const parseHeaders = createHeaders();
|
|
|
|
|
|
|
|
const parseBody = function(strs, ...values) {
|
|
|
|
let body = {};
|
|
|
|
const doubleBreak = strs.reduce(function(prev, item, i) {
|
|
|
|
// Ensure each line has no whitespace either end, including empty lines
|
|
|
|
item = item
|
|
|
|
.split('\n')
|
|
|
|
.map(item => item.trim())
|
|
|
|
.join('\n');
|
|
|
|
if (item.indexOf('\n\n') !== -1) {
|
|
|
|
return i;
|
2020-02-18 16:43:52 +00:00
|
|
|
}
|
|
|
|
return prev;
|
2020-07-07 18:58:46 +00:00
|
|
|
}, -1);
|
|
|
|
if (doubleBreak !== -1) {
|
|
|
|
// This merges request bodies together, so you can specify multiple bodies
|
|
|
|
// in the request and it will merge them together.
|
|
|
|
// Turns out we never actually do this, so it might be worth removing as it complicates
|
|
|
|
// matters slightly as we assumed post bodies would be an object.
|
|
|
|
// This actually works as it just uses the value of the first object, if its an array
|
|
|
|
// it concats
|
|
|
|
body = values.splice(doubleBreak).reduce(function(prev, item, i) {
|
|
|
|
switch (true) {
|
|
|
|
case Array.isArray(item):
|
|
|
|
if (i === 0) {
|
|
|
|
prev = [];
|
|
|
|
}
|
|
|
|
return prev.concat(item);
|
|
|
|
case typeof item !== 'string':
|
|
|
|
return {
|
|
|
|
...prev,
|
|
|
|
...item,
|
|
|
|
};
|
|
|
|
default:
|
|
|
|
return item;
|
|
|
|
}
|
|
|
|
}, body);
|
|
|
|
}
|
|
|
|
return [body, ...values];
|
2020-02-18 16:43:52 +00:00
|
|
|
};
|
2020-07-07 18:58:46 +00:00
|
|
|
|
2020-10-06 08:31:01 +00:00
|
|
|
const CLIENT_HEADERS = [CACHE_CONTROL, 'X-Request-ID', 'X-Range', 'Refresh'];
|
2020-11-09 09:25:35 +00:00
|
|
|
export default class HttpService extends Service {
|
ui: Adds Partitions to the HTTP layer (#10447)
This PR mainly adds partition to our HTTP adapter. Additionally and perhaps most importantly, we've also taken the opportunity to move our 'conditional namespaces' deeper into the app.
The reason for doing this was, we like that namespaces should be thought of as required instead of conditional, 'special' things and would like the same thinking to be applied to partitions.
Now, instead of using code throughout the app throughout the adapters to add/remove namespaces or partitions depending on whether they are enabled or not. As a UI engineer you just pretend that namespaces and partitions are always enabled, and we remove them for you deeper in the app, out of the way of you forgetting to treat these properties as a special case.
Notes:
Added a PartitionAbility while we were there (not used as yet)
Started to remove the CONSTANT variables we had just for property names. I prefer that our adapters are as readable and straightforwards as possible, it just looks like HTTP.
We'll probably remove our formatDatacenter method we use also at some point, it was mainly too make it look the same as our previous formatNspace, but now we don't have that, it instead now looks different!
We enable parsing of partition in the UIs URL, but this is feature flagged so still does nothing just yet.
All of the test changes were related to the fact that we were treating client.url as a function rather than a method, and now that we reference this in client.url (etc) it needs binding to client.
2021-09-15 17:09:55 +00:00
|
|
|
@service('dom') dom;
|
|
|
|
@service('env') env;
|
|
|
|
@service('client/connections') connections;
|
|
|
|
@service('client/transports/xhr') transport;
|
|
|
|
@service('settings') settings;
|
2020-11-09 09:25:35 +00:00
|
|
|
|
|
|
|
init() {
|
|
|
|
super.init(...arguments);
|
2020-05-27 10:23:21 +00:00
|
|
|
this._listeners = this.dom.listeners();
|
ui: Adds Partitions to the HTTP layer (#10447)
This PR mainly adds partition to our HTTP adapter. Additionally and perhaps most importantly, we've also taken the opportunity to move our 'conditional namespaces' deeper into the app.
The reason for doing this was, we like that namespaces should be thought of as required instead of conditional, 'special' things and would like the same thinking to be applied to partitions.
Now, instead of using code throughout the app throughout the adapters to add/remove namespaces or partitions depending on whether they are enabled or not. As a UI engineer you just pretend that namespaces and partitions are always enabled, and we remove them for you deeper in the app, out of the way of you forgetting to treat these properties as a special case.
Notes:
Added a PartitionAbility while we were there (not used as yet)
Started to remove the CONSTANT variables we had just for property names. I prefer that our adapters are as readable and straightforwards as possible, it just looks like HTTP.
We'll probably remove our formatDatacenter method we use also at some point, it was mainly too make it look the same as our previous formatNspace, but now we don't have that, it instead now looks different!
We enable parsing of partition in the UIs URL, but this is feature flagged so still does nothing just yet.
All of the test changes were related to the fact that we were treating client.url as a function rather than a method, and now that we reference this in client.url (etc) it needs binding to client.
2021-09-15 17:09:55 +00:00
|
|
|
this.parseURL = createURL(encodeURIComponent, obj => QueryParams.stringify(this.sanitize(obj)));
|
|
|
|
}
|
|
|
|
|
|
|
|
sanitize(obj) {
|
|
|
|
if (!this.env.var('CONSUL_NSPACES_ENABLED')) {
|
|
|
|
delete obj.ns;
|
|
|
|
} else {
|
|
|
|
if (typeof obj.ns === 'undefined' || obj.ns === null || obj.ns === '') {
|
|
|
|
delete obj.ns;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!this.env.var('CONSUL_PARTITIONS_ENABLED')) {
|
|
|
|
delete obj.partition;
|
|
|
|
} else {
|
|
|
|
if (typeof obj.partition === 'undefined' || obj.partition === null || obj.partition === '') {
|
|
|
|
delete obj.partition;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return obj;
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
willDestroy() {
|
2020-05-27 10:23:21 +00:00
|
|
|
this._listeners.remove();
|
2020-11-09 09:25:35 +00:00
|
|
|
super.willDestroy(...arguments);
|
|
|
|
}
|
|
|
|
|
|
|
|
url() {
|
ui: Adds Partitions to the HTTP layer (#10447)
This PR mainly adds partition to our HTTP adapter. Additionally and perhaps most importantly, we've also taken the opportunity to move our 'conditional namespaces' deeper into the app.
The reason for doing this was, we like that namespaces should be thought of as required instead of conditional, 'special' things and would like the same thinking to be applied to partitions.
Now, instead of using code throughout the app throughout the adapters to add/remove namespaces or partitions depending on whether they are enabled or not. As a UI engineer you just pretend that namespaces and partitions are always enabled, and we remove them for you deeper in the app, out of the way of you forgetting to treat these properties as a special case.
Notes:
Added a PartitionAbility while we were there (not used as yet)
Started to remove the CONSTANT variables we had just for property names. I prefer that our adapters are as readable and straightforwards as possible, it just looks like HTTP.
We'll probably remove our formatDatacenter method we use also at some point, it was mainly too make it look the same as our previous formatNspace, but now we don't have that, it instead now looks different!
We enable parsing of partition in the UIs URL, but this is feature flagged so still does nothing just yet.
All of the test changes were related to the fact that we were treating client.url as a function rather than a method, and now that we reference this in client.url (etc) it needs binding to client.
2021-09-15 17:09:55 +00:00
|
|
|
return this.parseURL(...arguments);
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
body() {
|
ui: Adds Partitions to the HTTP layer (#10447)
This PR mainly adds partition to our HTTP adapter. Additionally and perhaps most importantly, we've also taken the opportunity to move our 'conditional namespaces' deeper into the app.
The reason for doing this was, we like that namespaces should be thought of as required instead of conditional, 'special' things and would like the same thinking to be applied to partitions.
Now, instead of using code throughout the app throughout the adapters to add/remove namespaces or partitions depending on whether they are enabled or not. As a UI engineer you just pretend that namespaces and partitions are always enabled, and we remove them for you deeper in the app, out of the way of you forgetting to treat these properties as a special case.
Notes:
Added a PartitionAbility while we were there (not used as yet)
Started to remove the CONSTANT variables we had just for property names. I prefer that our adapters are as readable and straightforwards as possible, it just looks like HTTP.
We'll probably remove our formatDatacenter method we use also at some point, it was mainly too make it look the same as our previous formatNspace, but now we don't have that, it instead now looks different!
We enable parsing of partition in the UIs URL, but this is feature flagged so still does nothing just yet.
All of the test changes were related to the fact that we were treating client.url as a function rather than a method, and now that we reference this in client.url (etc) it needs binding to client.
2021-09-15 17:09:55 +00:00
|
|
|
const res = parseBody(...arguments);
|
|
|
|
this.sanitize(res[0]);
|
|
|
|
return res;
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
requestParams(strs, ...values) {
|
2020-07-07 18:58:46 +00:00
|
|
|
// first go to the end and remove/parse the http body
|
|
|
|
const [body, ...urlVars] = this.body(...arguments);
|
|
|
|
// with whats left get the method off the front
|
|
|
|
const [method, ...urlParts] = this.url(strs, ...urlVars).split(' ');
|
|
|
|
// with whats left use the rest of the line for the url
|
|
|
|
// with whats left after the line, use for the headers
|
|
|
|
const [url, ...headerParts] = urlParts.join(' ').split('\n');
|
|
|
|
const params = {
|
|
|
|
url: url.trim(),
|
|
|
|
method: method.trim(),
|
|
|
|
headers: {
|
|
|
|
[CONTENT_TYPE]: 'application/json; charset=utf-8',
|
|
|
|
...parseHeaders(headerParts),
|
|
|
|
},
|
|
|
|
body: null,
|
|
|
|
data: body,
|
|
|
|
};
|
|
|
|
// Remove and save things that shouldn't be sent in the request
|
|
|
|
params.clientHeaders = CLIENT_HEADERS.reduce(function(prev, item) {
|
|
|
|
if (typeof params.headers[item] !== 'undefined') {
|
|
|
|
prev[item.toLowerCase()] = params.headers[item];
|
|
|
|
delete params.headers[item];
|
2020-02-18 16:43:52 +00:00
|
|
|
}
|
|
|
|
return prev;
|
2020-07-07 18:58:46 +00:00
|
|
|
}, {});
|
|
|
|
if (typeof body !== 'undefined') {
|
|
|
|
// Only read add HTTP body if we aren't GET
|
|
|
|
// Right now we do this to avoid having to put data in the templates
|
|
|
|
// for write-like actions
|
|
|
|
// potentially we should change things so you _have_ to do that
|
|
|
|
// as doing it this way is a little magical
|
|
|
|
if (params.method !== 'GET') {
|
|
|
|
if (params.headers[CONTENT_TYPE].indexOf('json') !== -1) {
|
|
|
|
params.body = JSON.stringify(params.data);
|
|
|
|
} else {
|
|
|
|
if (
|
|
|
|
(typeof params.data === 'string' && params.data.length > 0) ||
|
|
|
|
Object.keys(params.data).length > 0
|
|
|
|
) {
|
|
|
|
params.body = params.data;
|
|
|
|
}
|
2020-02-18 16:43:52 +00:00
|
|
|
}
|
2020-07-07 18:58:46 +00:00
|
|
|
} else {
|
ui: Adds Partitions to the HTTP layer (#10447)
This PR mainly adds partition to our HTTP adapter. Additionally and perhaps most importantly, we've also taken the opportunity to move our 'conditional namespaces' deeper into the app.
The reason for doing this was, we like that namespaces should be thought of as required instead of conditional, 'special' things and would like the same thinking to be applied to partitions.
Now, instead of using code throughout the app throughout the adapters to add/remove namespaces or partitions depending on whether they are enabled or not. As a UI engineer you just pretend that namespaces and partitions are always enabled, and we remove them for you deeper in the app, out of the way of you forgetting to treat these properties as a special case.
Notes:
Added a PartitionAbility while we were there (not used as yet)
Started to remove the CONSTANT variables we had just for property names. I prefer that our adapters are as readable and straightforwards as possible, it just looks like HTTP.
We'll probably remove our formatDatacenter method we use also at some point, it was mainly too make it look the same as our previous formatNspace, but now we don't have that, it instead now looks different!
We enable parsing of partition in the UIs URL, but this is feature flagged so still does nothing just yet.
All of the test changes were related to the fact that we were treating client.url as a function rather than a method, and now that we reference this in client.url (etc) it needs binding to client.
2021-09-15 17:09:55 +00:00
|
|
|
const str = QueryParams.stringify(params.data);
|
2020-07-07 18:58:46 +00:00
|
|
|
if (str.length > 0) {
|
|
|
|
if (params.url.indexOf('?') !== -1) {
|
|
|
|
params.url = `${params.url}&${str}`;
|
|
|
|
} else {
|
|
|
|
params.url = `${params.url}?${str}`;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-02-18 16:43:52 +00:00
|
|
|
}
|
2020-07-07 18:58:46 +00:00
|
|
|
// temporarily reset the headers/content-type so it works the same
|
|
|
|
// as previously, should be able to remove this once the data layer
|
|
|
|
// rewrite is over and we can assert sending via form-encoded is fine
|
|
|
|
// also see adapters/kv content-types in requestForCreate/UpdateRecord
|
|
|
|
// also see https://github.com/hashicorp/consul/issues/3804
|
|
|
|
params.headers[CONTENT_TYPE] = 'application/json; charset=utf-8';
|
|
|
|
return params;
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
fetchWithToken(path, params) {
|
2020-11-04 09:33:37 +00:00
|
|
|
return this.settings.findBySlug('token').then(token => {
|
|
|
|
return fetch(`${path}`, {
|
|
|
|
...params,
|
|
|
|
headers: {
|
|
|
|
'X-Consul-Token': typeof token.SecretID === 'undefined' ? '' : token.SecretID,
|
|
|
|
...params.headers,
|
|
|
|
},
|
|
|
|
});
|
|
|
|
});
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
request(cb) {
|
ui: UI Release Merge (ui-staging merge) (#6527)
## HTTPAdapter (#5637)
## Ember upgrade 2.18 > 3.12 (#6448)
### Proxies can no longer get away with not calling _super
This means that we can't use create anymore to define dynamic methods.
Therefore we dynamically make 2 extended Proxies on demand, and then
create from those. Therefore we can call _super in the init method of
the extended Proxies.
### We aren't allowed to reset a service anymore
We never actually need to now anyway, this is a remnant of the refactor
from browser based confirmations. We fix it as simply as possible here
but will revisit and remove the old browser confirm functionality at a
later date
### Revert classes to use ES5 style to workaround babel transp. probs
Using a mixture of ES6 classes (and hence super) and arrow functions
means that when babel transpiles the arrow functions down to ES5, a
reference to this is moved before the call to super, hence causing a js
error.
Furthermore, we the testing environment no longer lets use use
apply/call on the constructor.
These errors only manifests during testing (only in the testing
environment), the application itself runs fine with no problems without
this change.
Using ES5 style class definitions give us freedom to do all of the above
without causing any errors, so we reverted these classes back to ES5
class definitions
### Skip test that seems to have changed due to a change in RSVP timing
This test tests a usecase/area of the API that will probably never ever
be used, it was more testing out the API. We've skipped the test for now
as this doesn't affect the application itself, but left a note to come
back here later to investigate further
### Remove enumerableContentDidChange
Initial testing looks like we don't need to call this function anymore,
the function no longer exists
### Rework Changeset.isSaving to take into account new ember APIs
Setting/hanging a computedProperty of an instantiated object no longer
works. Move to setting it on the prototype/class definition instead
### Change how we detect whether something requires listening
New ember API's have changed how you can detect whether something is a
computedProperty or not. It's not immediately clear if its even possible
now. Therefore we change how we detect whether something should be
listened to or not by just looking for presence of `addEventListener`
### Potentially temporary change of ci test scripts to ensure deps exist
All our tooling scripts run through a Makefile (for people familiar with
only using those), which then call yarn scripts which can be called
independently (for people familar with only using yarn).
The Makefile targets always check to make sure all the dependencies are
installed before running anything that requires them (building, testing
etc).
The CI scripts/targets didn't follow this same route and called the yarn
scripts directly (usually CI builds a cache of the dependencies first).
For some reason this cache isn't doing what it usually does, and it
looks as though, in CI, ember isn't installed.
This commit makes the CI scripts consistently use the same method as all
of the other tooling scripts (Makefile target > Install Deps if
required > call yarn script). This should install the dependencies if
for some reason the CI cache building doesn't complete/isn't successful.
Potentially this commit may be reverted if, the root of the problem is
elsewhere, although consistency is always good, so it might be a good
idea to leave this commit as is even if we need to debug and fix things
elsewhere.
### Make test-parallel consistent with the rest of the tooling scripts
As we are here making changes for CI purposes (making test-ci
consistent), we spotted that test-parallel is also inconsistent and also
the README manual instructions won't work without `ember` installed
globally.
This commit makes everything consistent and changes the manual
instructions to use the local ember instance that gets installed via
yarn
### Re-wrangle catchable to fit with new ember 3.12 APIs
In the upgrade from ember 3.8 > 3.12 the public interfaces for
ComputedProperties have changed slightly. `meta` is no longer a public
property of ComputedProperty but of a ComputedDecoratorImpl mixin
instead.
https://github.com/emberjs/ember.js/blob/7e4ba1096e3c2e3e0dde186d5ca52ff19cb8720a/packages/%40ember/-internals/metal/lib/computed.ts#L725
There seems to be no way, by just using publically available
methods, to replicate this behaviour so that we can create our own
'ComputedProperty` factory via injecting the ComputedProperty class as
we did previously.
https://github.com/hashicorp/consul/blob/3f333bada181aaf6340523ca2268a28d1a7db214/ui-v2/app/utils/computed/factory.js#L1-L18
Instead we dynamically hang our `Catchable` `catch` method off the
instantiated ComputedProperty. In doing it like this `ComputedProperty`
has already has its `meta` method mixed in so we don't have to manually
mix it in ourselves (which doesn't seem possible)
This functionality is only used during our work in trying to ensure
our EventSource/BlockingQuery work was as 'ember-like' as possible (i.e.
using the traditional Route.model hooks and ember-like Controller
properties). Our ongoing/upcoming work on a componentized approach to
data a.k.a `<DataSource />` means we will be able to remove the majority
of the code involved here now that it seems to be under an amount of
flux in ember.
### Build bindata_assetfs.go with new UI changes
2019-09-30 13:47:49 +00:00
|
|
|
const client = this;
|
|
|
|
return cb(function(strs, ...values) {
|
2020-07-07 18:58:46 +00:00
|
|
|
const params = client.requestParams(...arguments);
|
|
|
|
return client.settings.findBySlug('token').then(token => {
|
|
|
|
const options = {
|
|
|
|
...params,
|
|
|
|
headers: {
|
2020-05-05 16:29:35 +00:00
|
|
|
[CONSUL_TOKEN]: typeof token.SecretID === 'undefined' ? '' : token.SecretID,
|
2020-07-07 18:58:46 +00:00
|
|
|
...params.headers,
|
ui: UI Release Merge (ui-staging merge) (#6527)
## HTTPAdapter (#5637)
## Ember upgrade 2.18 > 3.12 (#6448)
### Proxies can no longer get away with not calling _super
This means that we can't use create anymore to define dynamic methods.
Therefore we dynamically make 2 extended Proxies on demand, and then
create from those. Therefore we can call _super in the init method of
the extended Proxies.
### We aren't allowed to reset a service anymore
We never actually need to now anyway, this is a remnant of the refactor
from browser based confirmations. We fix it as simply as possible here
but will revisit and remove the old browser confirm functionality at a
later date
### Revert classes to use ES5 style to workaround babel transp. probs
Using a mixture of ES6 classes (and hence super) and arrow functions
means that when babel transpiles the arrow functions down to ES5, a
reference to this is moved before the call to super, hence causing a js
error.
Furthermore, we the testing environment no longer lets use use
apply/call on the constructor.
These errors only manifests during testing (only in the testing
environment), the application itself runs fine with no problems without
this change.
Using ES5 style class definitions give us freedom to do all of the above
without causing any errors, so we reverted these classes back to ES5
class definitions
### Skip test that seems to have changed due to a change in RSVP timing
This test tests a usecase/area of the API that will probably never ever
be used, it was more testing out the API. We've skipped the test for now
as this doesn't affect the application itself, but left a note to come
back here later to investigate further
### Remove enumerableContentDidChange
Initial testing looks like we don't need to call this function anymore,
the function no longer exists
### Rework Changeset.isSaving to take into account new ember APIs
Setting/hanging a computedProperty of an instantiated object no longer
works. Move to setting it on the prototype/class definition instead
### Change how we detect whether something requires listening
New ember API's have changed how you can detect whether something is a
computedProperty or not. It's not immediately clear if its even possible
now. Therefore we change how we detect whether something should be
listened to or not by just looking for presence of `addEventListener`
### Potentially temporary change of ci test scripts to ensure deps exist
All our tooling scripts run through a Makefile (for people familiar with
only using those), which then call yarn scripts which can be called
independently (for people familar with only using yarn).
The Makefile targets always check to make sure all the dependencies are
installed before running anything that requires them (building, testing
etc).
The CI scripts/targets didn't follow this same route and called the yarn
scripts directly (usually CI builds a cache of the dependencies first).
For some reason this cache isn't doing what it usually does, and it
looks as though, in CI, ember isn't installed.
This commit makes the CI scripts consistently use the same method as all
of the other tooling scripts (Makefile target > Install Deps if
required > call yarn script). This should install the dependencies if
for some reason the CI cache building doesn't complete/isn't successful.
Potentially this commit may be reverted if, the root of the problem is
elsewhere, although consistency is always good, so it might be a good
idea to leave this commit as is even if we need to debug and fix things
elsewhere.
### Make test-parallel consistent with the rest of the tooling scripts
As we are here making changes for CI purposes (making test-ci
consistent), we spotted that test-parallel is also inconsistent and also
the README manual instructions won't work without `ember` installed
globally.
This commit makes everything consistent and changes the manual
instructions to use the local ember instance that gets installed via
yarn
### Re-wrangle catchable to fit with new ember 3.12 APIs
In the upgrade from ember 3.8 > 3.12 the public interfaces for
ComputedProperties have changed slightly. `meta` is no longer a public
property of ComputedProperty but of a ComputedDecoratorImpl mixin
instead.
https://github.com/emberjs/ember.js/blob/7e4ba1096e3c2e3e0dde186d5ca52ff19cb8720a/packages/%40ember/-internals/metal/lib/computed.ts#L725
There seems to be no way, by just using publically available
methods, to replicate this behaviour so that we can create our own
'ComputedProperty` factory via injecting the ComputedProperty class as
we did previously.
https://github.com/hashicorp/consul/blob/3f333bada181aaf6340523ca2268a28d1a7db214/ui-v2/app/utils/computed/factory.js#L1-L18
Instead we dynamically hang our `Catchable` `catch` method off the
instantiated ComputedProperty. In doing it like this `ComputedProperty`
has already has its `meta` method mixed in so we don't have to manually
mix it in ourselves (which doesn't seem possible)
This functionality is only used during our work in trying to ensure
our EventSource/BlockingQuery work was as 'ember-like' as possible (i.e.
using the traditional Route.model hooks and ember-like Controller
properties). Our ongoing/upcoming work on a componentized approach to
data a.k.a `<DataSource />` means we will be able to remove the majority
of the code involved here now that it seems to be under an amount of
flux in ember.
### Build bindata_assetfs.go with new UI changes
2019-09-30 13:47:49 +00:00
|
|
|
},
|
2020-03-03 14:55:49 +00:00
|
|
|
};
|
2020-07-07 18:58:46 +00:00
|
|
|
const request = client.transport.request(options);
|
|
|
|
return new Promise((resolve, reject) => {
|
|
|
|
const remove = client._listeners.add(request, {
|
|
|
|
open: e => {
|
|
|
|
client.acquire(e.target);
|
2020-03-03 14:55:49 +00:00
|
|
|
},
|
2020-07-07 18:58:46 +00:00
|
|
|
message: e => {
|
|
|
|
const headers = {
|
|
|
|
...Object.entries(e.data.headers).reduce(function(prev, [key, value], i) {
|
|
|
|
if (!CLIENT_HEADERS.includes(key)) {
|
|
|
|
prev[key] = value;
|
|
|
|
}
|
|
|
|
return prev;
|
|
|
|
}, {}),
|
|
|
|
...params.clientHeaders,
|
ui: Adds Partitions to the HTTP layer (#10447)
This PR mainly adds partition to our HTTP adapter. Additionally and perhaps most importantly, we've also taken the opportunity to move our 'conditional namespaces' deeper into the app.
The reason for doing this was, we like that namespaces should be thought of as required instead of conditional, 'special' things and would like the same thinking to be applied to partitions.
Now, instead of using code throughout the app throughout the adapters to add/remove namespaces or partitions depending on whether they are enabled or not. As a UI engineer you just pretend that namespaces and partitions are always enabled, and we remove them for you deeper in the app, out of the way of you forgetting to treat these properties as a special case.
Notes:
Added a PartitionAbility while we were there (not used as yet)
Started to remove the CONSTANT variables we had just for property names. I prefer that our adapters are as readable and straightforwards as possible, it just looks like HTTP.
We'll probably remove our formatDatacenter method we use also at some point, it was mainly too make it look the same as our previous formatNspace, but now we don't have that, it instead now looks different!
We enable parsing of partition in the UIs URL, but this is feature flagged so still does nothing just yet.
All of the test changes were related to the fact that we were treating client.url as a function rather than a method, and now that we reference this in client.url (etc) it needs binding to client.
2021-09-15 17:09:55 +00:00
|
|
|
// Add a 'pretend' Datacenter/Nspace header, they are not
|
|
|
|
// headers the come from the request but we add them here so
|
|
|
|
// we can use them later for store reconciliation.
|
|
|
|
// Namespace will look at the ns query parameter first,
|
|
|
|
// followed by the Namespace property of the users token,
|
|
|
|
// defaulting back to 'default' which will mainly be used in
|
|
|
|
// OSS
|
|
|
|
[CONSUL_DATACENTER]: params.data.dc,
|
|
|
|
[CONSUL_NAMESPACE]: params.data.ns || token.Namespace || 'default',
|
2020-07-07 18:58:46 +00:00
|
|
|
};
|
2020-03-03 14:55:49 +00:00
|
|
|
const respond = function(cb) {
|
2020-07-07 18:58:46 +00:00
|
|
|
return cb(headers, e.data.response);
|
2020-03-03 14:55:49 +00:00
|
|
|
};
|
2020-07-07 18:58:46 +00:00
|
|
|
next(() => resolve(respond));
|
2020-03-03 14:55:49 +00:00
|
|
|
},
|
2020-07-07 18:58:46 +00:00
|
|
|
error: e => {
|
|
|
|
next(() => reject(e.error));
|
ui: UI Release Merge (ui-staging merge) (#6527)
## HTTPAdapter (#5637)
## Ember upgrade 2.18 > 3.12 (#6448)
### Proxies can no longer get away with not calling _super
This means that we can't use create anymore to define dynamic methods.
Therefore we dynamically make 2 extended Proxies on demand, and then
create from those. Therefore we can call _super in the init method of
the extended Proxies.
### We aren't allowed to reset a service anymore
We never actually need to now anyway, this is a remnant of the refactor
from browser based confirmations. We fix it as simply as possible here
but will revisit and remove the old browser confirm functionality at a
later date
### Revert classes to use ES5 style to workaround babel transp. probs
Using a mixture of ES6 classes (and hence super) and arrow functions
means that when babel transpiles the arrow functions down to ES5, a
reference to this is moved before the call to super, hence causing a js
error.
Furthermore, we the testing environment no longer lets use use
apply/call on the constructor.
These errors only manifests during testing (only in the testing
environment), the application itself runs fine with no problems without
this change.
Using ES5 style class definitions give us freedom to do all of the above
without causing any errors, so we reverted these classes back to ES5
class definitions
### Skip test that seems to have changed due to a change in RSVP timing
This test tests a usecase/area of the API that will probably never ever
be used, it was more testing out the API. We've skipped the test for now
as this doesn't affect the application itself, but left a note to come
back here later to investigate further
### Remove enumerableContentDidChange
Initial testing looks like we don't need to call this function anymore,
the function no longer exists
### Rework Changeset.isSaving to take into account new ember APIs
Setting/hanging a computedProperty of an instantiated object no longer
works. Move to setting it on the prototype/class definition instead
### Change how we detect whether something requires listening
New ember API's have changed how you can detect whether something is a
computedProperty or not. It's not immediately clear if its even possible
now. Therefore we change how we detect whether something should be
listened to or not by just looking for presence of `addEventListener`
### Potentially temporary change of ci test scripts to ensure deps exist
All our tooling scripts run through a Makefile (for people familiar with
only using those), which then call yarn scripts which can be called
independently (for people familar with only using yarn).
The Makefile targets always check to make sure all the dependencies are
installed before running anything that requires them (building, testing
etc).
The CI scripts/targets didn't follow this same route and called the yarn
scripts directly (usually CI builds a cache of the dependencies first).
For some reason this cache isn't doing what it usually does, and it
looks as though, in CI, ember isn't installed.
This commit makes the CI scripts consistently use the same method as all
of the other tooling scripts (Makefile target > Install Deps if
required > call yarn script). This should install the dependencies if
for some reason the CI cache building doesn't complete/isn't successful.
Potentially this commit may be reverted if, the root of the problem is
elsewhere, although consistency is always good, so it might be a good
idea to leave this commit as is even if we need to debug and fix things
elsewhere.
### Make test-parallel consistent with the rest of the tooling scripts
As we are here making changes for CI purposes (making test-ci
consistent), we spotted that test-parallel is also inconsistent and also
the README manual instructions won't work without `ember` installed
globally.
This commit makes everything consistent and changes the manual
instructions to use the local ember instance that gets installed via
yarn
### Re-wrangle catchable to fit with new ember 3.12 APIs
In the upgrade from ember 3.8 > 3.12 the public interfaces for
ComputedProperties have changed slightly. `meta` is no longer a public
property of ComputedProperty but of a ComputedDecoratorImpl mixin
instead.
https://github.com/emberjs/ember.js/blob/7e4ba1096e3c2e3e0dde186d5ca52ff19cb8720a/packages/%40ember/-internals/metal/lib/computed.ts#L725
There seems to be no way, by just using publically available
methods, to replicate this behaviour so that we can create our own
'ComputedProperty` factory via injecting the ComputedProperty class as
we did previously.
https://github.com/hashicorp/consul/blob/3f333bada181aaf6340523ca2268a28d1a7db214/ui-v2/app/utils/computed/factory.js#L1-L18
Instead we dynamically hang our `Catchable` `catch` method off the
instantiated ComputedProperty. In doing it like this `ComputedProperty`
has already has its `meta` method mixed in so we don't have to manually
mix it in ourselves (which doesn't seem possible)
This functionality is only used during our work in trying to ensure
our EventSource/BlockingQuery work was as 'ember-like' as possible (i.e.
using the traditional Route.model hooks and ember-like Controller
properties). Our ongoing/upcoming work on a componentized approach to
data a.k.a `<DataSource />` means we will be able to remove the majority
of the code involved here now that it seems to be under an amount of
flux in ember.
### Build bindata_assetfs.go with new UI changes
2019-09-30 13:47:49 +00:00
|
|
|
},
|
2020-07-07 18:58:46 +00:00
|
|
|
close: e => {
|
|
|
|
client.release(e.target);
|
|
|
|
remove();
|
2020-03-03 14:55:49 +00:00
|
|
|
},
|
2020-07-07 18:58:46 +00:00
|
|
|
});
|
|
|
|
request.fetch();
|
2020-03-03 14:55:49 +00:00
|
|
|
});
|
ui: UI Release Merge (ui-staging merge) (#6527)
## HTTPAdapter (#5637)
## Ember upgrade 2.18 > 3.12 (#6448)
### Proxies can no longer get away with not calling _super
This means that we can't use create anymore to define dynamic methods.
Therefore we dynamically make 2 extended Proxies on demand, and then
create from those. Therefore we can call _super in the init method of
the extended Proxies.
### We aren't allowed to reset a service anymore
We never actually need to now anyway, this is a remnant of the refactor
from browser based confirmations. We fix it as simply as possible here
but will revisit and remove the old browser confirm functionality at a
later date
### Revert classes to use ES5 style to workaround babel transp. probs
Using a mixture of ES6 classes (and hence super) and arrow functions
means that when babel transpiles the arrow functions down to ES5, a
reference to this is moved before the call to super, hence causing a js
error.
Furthermore, we the testing environment no longer lets use use
apply/call on the constructor.
These errors only manifests during testing (only in the testing
environment), the application itself runs fine with no problems without
this change.
Using ES5 style class definitions give us freedom to do all of the above
without causing any errors, so we reverted these classes back to ES5
class definitions
### Skip test that seems to have changed due to a change in RSVP timing
This test tests a usecase/area of the API that will probably never ever
be used, it was more testing out the API. We've skipped the test for now
as this doesn't affect the application itself, but left a note to come
back here later to investigate further
### Remove enumerableContentDidChange
Initial testing looks like we don't need to call this function anymore,
the function no longer exists
### Rework Changeset.isSaving to take into account new ember APIs
Setting/hanging a computedProperty of an instantiated object no longer
works. Move to setting it on the prototype/class definition instead
### Change how we detect whether something requires listening
New ember API's have changed how you can detect whether something is a
computedProperty or not. It's not immediately clear if its even possible
now. Therefore we change how we detect whether something should be
listened to or not by just looking for presence of `addEventListener`
### Potentially temporary change of ci test scripts to ensure deps exist
All our tooling scripts run through a Makefile (for people familiar with
only using those), which then call yarn scripts which can be called
independently (for people familar with only using yarn).
The Makefile targets always check to make sure all the dependencies are
installed before running anything that requires them (building, testing
etc).
The CI scripts/targets didn't follow this same route and called the yarn
scripts directly (usually CI builds a cache of the dependencies first).
For some reason this cache isn't doing what it usually does, and it
looks as though, in CI, ember isn't installed.
This commit makes the CI scripts consistently use the same method as all
of the other tooling scripts (Makefile target > Install Deps if
required > call yarn script). This should install the dependencies if
for some reason the CI cache building doesn't complete/isn't successful.
Potentially this commit may be reverted if, the root of the problem is
elsewhere, although consistency is always good, so it might be a good
idea to leave this commit as is even if we need to debug and fix things
elsewhere.
### Make test-parallel consistent with the rest of the tooling scripts
As we are here making changes for CI purposes (making test-ci
consistent), we spotted that test-parallel is also inconsistent and also
the README manual instructions won't work without `ember` installed
globally.
This commit makes everything consistent and changes the manual
instructions to use the local ember instance that gets installed via
yarn
### Re-wrangle catchable to fit with new ember 3.12 APIs
In the upgrade from ember 3.8 > 3.12 the public interfaces for
ComputedProperties have changed slightly. `meta` is no longer a public
property of ComputedProperty but of a ComputedDecoratorImpl mixin
instead.
https://github.com/emberjs/ember.js/blob/7e4ba1096e3c2e3e0dde186d5ca52ff19cb8720a/packages/%40ember/-internals/metal/lib/computed.ts#L725
There seems to be no way, by just using publically available
methods, to replicate this behaviour so that we can create our own
'ComputedProperty` factory via injecting the ComputedProperty class as
we did previously.
https://github.com/hashicorp/consul/blob/3f333bada181aaf6340523ca2268a28d1a7db214/ui-v2/app/utils/computed/factory.js#L1-L18
Instead we dynamically hang our `Catchable` `catch` method off the
instantiated ComputedProperty. In doing it like this `ComputedProperty`
has already has its `meta` method mixed in so we don't have to manually
mix it in ourselves (which doesn't seem possible)
This functionality is only used during our work in trying to ensure
our EventSource/BlockingQuery work was as 'ember-like' as possible (i.e.
using the traditional Route.model hooks and ember-like Controller
properties). Our ongoing/upcoming work on a componentized approach to
data a.k.a `<DataSource />` means we will be able to remove the majority
of the code involved here now that it seems to be under an amount of
flux in ember.
### Build bindata_assetfs.go with new UI changes
2019-09-30 13:47:49 +00:00
|
|
|
});
|
|
|
|
});
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
whenAvailable(e) {
|
2020-07-07 18:58:46 +00:00
|
|
|
return this.connections.whenAvailable(e);
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
abort() {
|
2020-07-07 18:58:46 +00:00
|
|
|
return this.connections.purge(...arguments);
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
acquire() {
|
2020-07-07 18:58:46 +00:00
|
|
|
return this.connections.acquire(...arguments);
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
release() {
|
ui: UI Release Merge (ui-staging merge) (#6527)
## HTTPAdapter (#5637)
## Ember upgrade 2.18 > 3.12 (#6448)
### Proxies can no longer get away with not calling _super
This means that we can't use create anymore to define dynamic methods.
Therefore we dynamically make 2 extended Proxies on demand, and then
create from those. Therefore we can call _super in the init method of
the extended Proxies.
### We aren't allowed to reset a service anymore
We never actually need to now anyway, this is a remnant of the refactor
from browser based confirmations. We fix it as simply as possible here
but will revisit and remove the old browser confirm functionality at a
later date
### Revert classes to use ES5 style to workaround babel transp. probs
Using a mixture of ES6 classes (and hence super) and arrow functions
means that when babel transpiles the arrow functions down to ES5, a
reference to this is moved before the call to super, hence causing a js
error.
Furthermore, we the testing environment no longer lets use use
apply/call on the constructor.
These errors only manifests during testing (only in the testing
environment), the application itself runs fine with no problems without
this change.
Using ES5 style class definitions give us freedom to do all of the above
without causing any errors, so we reverted these classes back to ES5
class definitions
### Skip test that seems to have changed due to a change in RSVP timing
This test tests a usecase/area of the API that will probably never ever
be used, it was more testing out the API. We've skipped the test for now
as this doesn't affect the application itself, but left a note to come
back here later to investigate further
### Remove enumerableContentDidChange
Initial testing looks like we don't need to call this function anymore,
the function no longer exists
### Rework Changeset.isSaving to take into account new ember APIs
Setting/hanging a computedProperty of an instantiated object no longer
works. Move to setting it on the prototype/class definition instead
### Change how we detect whether something requires listening
New ember API's have changed how you can detect whether something is a
computedProperty or not. It's not immediately clear if its even possible
now. Therefore we change how we detect whether something should be
listened to or not by just looking for presence of `addEventListener`
### Potentially temporary change of ci test scripts to ensure deps exist
All our tooling scripts run through a Makefile (for people familiar with
only using those), which then call yarn scripts which can be called
independently (for people familar with only using yarn).
The Makefile targets always check to make sure all the dependencies are
installed before running anything that requires them (building, testing
etc).
The CI scripts/targets didn't follow this same route and called the yarn
scripts directly (usually CI builds a cache of the dependencies first).
For some reason this cache isn't doing what it usually does, and it
looks as though, in CI, ember isn't installed.
This commit makes the CI scripts consistently use the same method as all
of the other tooling scripts (Makefile target > Install Deps if
required > call yarn script). This should install the dependencies if
for some reason the CI cache building doesn't complete/isn't successful.
Potentially this commit may be reverted if, the root of the problem is
elsewhere, although consistency is always good, so it might be a good
idea to leave this commit as is even if we need to debug and fix things
elsewhere.
### Make test-parallel consistent with the rest of the tooling scripts
As we are here making changes for CI purposes (making test-ci
consistent), we spotted that test-parallel is also inconsistent and also
the README manual instructions won't work without `ember` installed
globally.
This commit makes everything consistent and changes the manual
instructions to use the local ember instance that gets installed via
yarn
### Re-wrangle catchable to fit with new ember 3.12 APIs
In the upgrade from ember 3.8 > 3.12 the public interfaces for
ComputedProperties have changed slightly. `meta` is no longer a public
property of ComputedProperty but of a ComputedDecoratorImpl mixin
instead.
https://github.com/emberjs/ember.js/blob/7e4ba1096e3c2e3e0dde186d5ca52ff19cb8720a/packages/%40ember/-internals/metal/lib/computed.ts#L725
There seems to be no way, by just using publically available
methods, to replicate this behaviour so that we can create our own
'ComputedProperty` factory via injecting the ComputedProperty class as
we did previously.
https://github.com/hashicorp/consul/blob/3f333bada181aaf6340523ca2268a28d1a7db214/ui-v2/app/utils/computed/factory.js#L1-L18
Instead we dynamically hang our `Catchable` `catch` method off the
instantiated ComputedProperty. In doing it like this `ComputedProperty`
has already has its `meta` method mixed in so we don't have to manually
mix it in ourselves (which doesn't seem possible)
This functionality is only used during our work in trying to ensure
our EventSource/BlockingQuery work was as 'ember-like' as possible (i.e.
using the traditional Route.model hooks and ember-like Controller
properties). Our ongoing/upcoming work on a componentized approach to
data a.k.a `<DataSource />` means we will be able to remove the majority
of the code involved here now that it seems to be under an amount of
flux in ember.
### Build bindata_assetfs.go with new UI changes
2019-09-30 13:47:49 +00:00
|
|
|
return this.connections.release(...arguments);
|
2020-11-09 09:25:35 +00:00
|
|
|
}
|
|
|
|
}
|