This is adapted from helpful posts in this thread:
ember-cli/ember-cli#2508

Without this, the origin header wasn’t being rewritten
so I was unable to open a websocket to the API running
on a different port.

The communication between the socket and xterm.js terminal
instance might better be extracted, I’m not sure whether
the component integration test even makes sense. I originally
tried an acceptance test, but that seemed worse.

# Conflicts:
#	ui/yarn.lock

This seems quite fiddly, hopefully not Too Much™ 😳

It’s not that much of a navbar even… just not sure about
how much sharing is even worth it here 🤔

This approach… not sure about it:
• how to test the contents of the terminal without
  storing on window?
• passing the terminal in seems a bit weird but
  otherwise was considering some event interface,
  but that seems like overkill…?!?

This isn’t responsive to resize events etc yet but at least
looks better.

This seems a bit strange but…? Maybe a component would
make sense to wrap everything in but then would it be
rerendering as you navigate deeper into the hierarchy…?

Maybe there’s some breakage if you navigate between
task groups and something closes that you opened yourself
but since I don’t anticipate actually changing the route
when you click a task group (vs a task, which will), it
seems safe to ignore.

I haven’t started to include allocations in all of this yet
so this is pretty unrealistic.

This is becoming quite sprawling but I believe having good
acceptance tests will help me clean up when I’ve covered
the myriad approaches.

ANSI escapes: wild times

I checked the default and it was this:
“courier-new, courier, monospace”

So a stack-ish thing does seem to be supported. I’m
using monospace now because that’s what’s used
elsewhere in the application, like job definitions.

This is edging toward overkill for acceptance tests. I’ll
perhaps extract some kind of utility or class to handle
connecting the editing of the command string to a terminal
so it can be more fully tested.

This isn’t exactly correct and is only manually tested at
the moment 😐

This is in preparation for extracting the item component.

These are superseded by the variable names.

This has felt necessary for a while but evaded me until
now. This should allow me to me more easily implement/test
a workaround for the lack of reverse-wraparound mode
as I describe here:

xtermjs/xterm.js#2716

I’ll likely extract another class that connects the exec
WebSocket to the terminal so everything’s not concentrated
in the controller and more edge cases can be easily exercised
in automated tests.

I keep forgetting this is the local pattern.

This leaves me well-positioned to add more extensive testing
for the command-editing, including copy/paste and maybe even
^U? This pattern can also apply to an extracted socket-
terminal adapter.

This seems to work…?!

Similarly to the command-editing adapter, this will
facilitate more involved tests than the acceptance
tests.

This prevents the layout/text-wrapping of the sidebar
from changing when a connexion has been opened.

This is a step toward properly informing the remote end
of the size of the terminal. Without it, line-wrapping
in the exec session is broken, among other things. This
will need to be expanded to handle when the window is
resized.

This is better but still lacking; before it wasn’t getting
taller than the default, but now it’s slightly too tall… meh

The problem the FIXME referred to was actually that the
height was 100% of the window, which failed to exclude
the height of the navbar.

I should have included this when checking the message sent…
though maybe this is unnecessary duplication?

This doesn’t do anything in this test.

I attempted to produce stderr frames but learned from
@notnoop that they won’t happen because of the tty
flag when opening the socket. There still needs to be
handling for other messages, such as stdout.close vs
stdout.data.

I don’t know why I was getting this error but it’s not
important enough to me to figure out vs just changing:
  329:8  error  Parsing error: Unexpected token =

This is a template lint requirement.

I should have included this in 894c5ec but sadly the unreliable
test situation is a problem I haven’t been able to address yet.

This was passing for me locally but failing on Circle CI,
not sure why, but the purpose is to make sure the numbers
match, the actual numbers aren’t important.

This is similar to the change needed for the acceptance
test. My theory now is that it’s because of font differences
across platforms.

There’s no need to actually change the container if the
specifics of the rows and columns aren’t being asserted
against.

This test was failing because the route’s attempt to find
the task state by name was impossible.

Later in this file, if the clientStatus is pending, the task
states don’t get connected to the allocation. This causes
tests to fail because that connexion is used in the exec
task route. Maybe when constructing the job another flag
needs to be threaded through… meh

This guarantees that the task, task state, and allocation
can be properly connected in the acceptance tests.