[FEAT] Add inspect store button to data pane in Ember Inspector #1163
Conversation
|
The code and functionality looks good to me. I'll leave it to @nummi see if there are any UI improvements to suggest. My initial thought is we should incorporate the Also, do you mind adding a test for this feature? |
Happy to add a test @chancancode, however I didn't see an example of one that tested things end-to-end (I could have missed it) or if it is ok to stub out a lot of the functionality. Perhaps you could point me in the right direction or provide some guidance? |
|
How does this look?
Or this?
|
|
@nummi @chancancode I updated the button to be the first suggested option. What do you think? |
|
IMO, the $E is important, since it tells you you can find it as that variable in the console, the > alone seems to generic to communicate that, so personally, I like the second option |
|
@chancancode not sure if this is clear in the gif but right now clicking on the |
|
ohhhh sorry I got it all wrong! In that case I agree there is no need for the > $E. My bad!! |
|
To be clear, I now think your original design, a button with just the label, is fine, since it doesn't actually send the store to the |
|
For the test, I think you can add an acceptance test in test('...', async function(assert) {
await visit('/data/model-types');
respondWith('objectInspector:inspectByContainerLookup', ({ name }) => {
assert.equal(name, 'service:store');
return false;
});
await click('[data-test-inspect-store]);
});
Alternatively, in step 2, we could set it up to send the proper response here (which would be sending the store service object from the "app" to the inspector). However, that would require quite a bit of set up, and then the inspector will send more messages to inspect the properties on the store service object, which, imo, are not really the point of this test. I think the functionality of the object inspector is already covered in other places, and in here we only really care about the button triggering the object inspector, so I think we can just stop there and trust that the object debug/inspector is going to do the right thing with that message (which is already covered elsewhere). |
SYU15
force-pushed
the
add-store
branch
5 times, most recently
from
7937092 to
db06951
Compare
SYU15
changed the title
While working on #1163, we encountered an issue with the test adapter, where unmet expectations (when you set up a `respondTo` for a test that was never triggered) did not cause the offending test to fail. Instead, they became unhandled promise rejections (i.e. "global errors") and fails the _next_ test that runs. This is because we were using the `QUnit.{testStart,testDone}` hooks as if they were a global version of `{before,after}Each`. However, the global hooks are really intended for things like test reporters and runs too late to affect things like the pass or fail status of a test. This commit introduces a `setupTestAdapter` function that uses the normal (not global) APIs so that the failures are attached to the correct test.
While working on #1163, we encountered an issue with the test adapter, where unmet expectations (when you set up a `respondTo` for a test that was never triggered) did not cause the offending test to fail. Instead, they became unhandled promise rejections (i.e. "global errors") and fails the _next_ test that runs. This is because we were using the `QUnit.{testStart,testDone}` hooks as if they were a global version of `{before,after}Each`. However, the global hooks are really intended for things like test reporters and runs too late to affect things like the pass or fail status of a test. This commit introduces a `setupTestAdapter` function that uses the normal (not global) APIs so that the failures are attached to the correct test.
While working on #1163, we encountered an issue with the test adapter, where unmet expectations (when you set up a `respondTo` for a test that was never triggered) did not cause the offending test to fail. Instead, they became unhandled promise rejections (i.e. "global errors") and fails the _next_ test that runs. This is because we were using the `QUnit.{testStart,testDone}` hooks as if they were a global version of `{before,after}Each`. However, the global hooks are really intended for things like test reporters and runs too late to affect things like the pass or fail status of a test. This commit introduces a `setupTestAdapter` function that uses the normal (not global) APIs so that the failures are attached to the correct test.
While working on emberjs#1163, we encountered an issue with the test adapter, where unmet expectations (when you set up a `respondTo` for a test that was never triggered) did not cause the offending test to fail. Instead, they became unhandled promise rejections (i.e. "global errors") and fails the _next_ test that runs. This is because we were using the `QUnit.{testStart,testDone}` hooks as if they were a global version of `{before,after}Each`. However, the global hooks are really intended for things like test reporters and runs too late to affect things like the pass or fail status of a test. This commit introduces a `setupTestAdapter` function that uses the normal (not global) APIs so that the failures are attached to the correct test.
While working on emberjs#1163, we encountered an issue with the test adapter, where unmet expectations (when you set up a `respondTo` for a test that was never triggered) did not cause the offending test to fail. Instead, they became unhandled promise rejections (i.e. "global errors") and fails the _next_ test that runs. This is because we were using the `QUnit.{testStart,testDone}` hooks as if they were a global version of `{before,after}Each`. However, the global hooks are really intended for things like test reporters and runs too late to affect things like the pass or fail status of a test. This commit introduces a `setupTestAdapter` function that uses the normal (not global) APIs so that the failures are attached to the correct test.
Description
Add a button in data pane to enable user to inspect store and send it to console.
Would love some guidance as to what a good test would be since a lot of the end-to-end functionality seems to be stubbed out in other tests.
Screenshots