Connect client-side with the server-side

[darcydriscoll]

Requirements

1. Client asks the server if we're already signed in
2. If the answer is 'true', then continue to chat room page
3. Else, wait for user to submit their desired nickname
4. Client asks the server if we can sign in with this nickname
5. If the answer is 'true', play tick animation, the continue to chat room page
6. Else, if the answer is 'false', and the error is 'nickname invalid', tell the user that the nickname is invalid (go to 3)
7. Else, if the answer is 'false', and the nickname is already taken, tell the user that the nickname is already taken (go to 3)
8. Else, if the answer is 'false', and the server doesn't know what happened, tell the user that there's been an error and to try again (go to 3)
9. Else, if we don't get an answer, tell the user that there's been an error and to try again (go to 3)

Notes

Remaining criteria as of 14/02/2022

• [x] Continue to chat room page (SPA - Vue Router library).
  • [x] Explore and understand essential Vue Router docs.
  • [x] Install Vue Router in my app.
  • [x] Design a method for continuing to the chat room and implement:
    • [x] Create a new 'page' -- the chat room page.
    • [x] Make a route for it.
    • [x] Programmatically go to that route when the nickname entry succeeds.
    • [x] Do the same when the auto-sign-in succeeds.
    • [x] Modify Apache server configuration as described in docs
    • [x] Assess whether any other server configuration needs to be done for usability. Nope!
    • [x] Redirect user on a logical, vue-router level when they try to get logical pages that don't exist.
    • [x] Take a step back and assess the necessity and feasibility of transition animations:
      • [x] Added a transition fade-in for the sign-in page. I won't be adding any more transitions in this story.
• [x] Play tick animation when nickname is accepted.
• [x] Explore error messages -- am I missing anything?
• [x] Implement error handling.
• [x] Reconsider session cookies lifetime. Extend to 30-60 days? Extended to 72 hours.
• [x] Either 1) refactor or 2) make a note to refactor later (through an Issues board?). See ideas here.
  • [x] Refactor error codes.
    • [x] Investigate csv and json libraries for PHP and JS. Using json.
    • [x] For PHP: use file_get_contents with json_decode. Put the file into a string and then transform it into an array.
    • [x] For JS:
      • [x] Loading in: Promise callback function that signals to the rest of SignIn.vue that we've loaded dependencies.
      • [x] Standardised client-side errors: Separate js file to load in, then merge with other array. Doesn't need to be json -- we just need it to be clear when changes are being made.
  • [x] Improve check mark colour when sign in succeeds.

[darcydriscoll]

Having trouble with Apache server configuration:

• When I set RewriteBase to "/", Apache doesn't start. Why?
• When I don't include RewriteBase, Apache starts. But pages don't load correctly. By the errors I'm getting, it seems that whenever the client tries to get the relevant JS files from the server, the server returns a file that starts with '<' instead. This is probably a .html file, and likely 'index.html'. Are the rewriting conditions too broad?

Maybe I could play around with the rewriting conditions and see what I find.

[darcydriscoll]

Having trouble with Apache server configuration:

• When I set RewriteBase to "/", Apache doesn't start. Why?

• When I don't include RewriteBase, Apache starts. But pages don't load correctly. By the errors I'm getting, it seems that whenever the client tries to get the relevant JS files from the server, the server returns a file that starts with '<' instead. This is probably a .html file, and likely 'index.html'. Are the rewriting conditions too broad?

Maybe I could play around with the rewriting conditions and see what I find.

Causes for both of these issues:

• RewriteBase isn't necessary to use outside of a per-directory or .htaccess context. I wasn't using it in either of those contexts, and because of that, it seems that Apache self-destructed.
• It was because of my RewriteCond statements. They each referenced the variable REQUEST_FILENAME. Ideally, REQUEST_FILENAME returns the full (absolute) filesystem path to the file. But they weren't in this case for some reason -- they were pointing to the path component of the requested URI (e.g. '/index.html'). RewriteCond in a server config context starts at the server's root directory. This meant that the RewriteCond conditions were always passing, because something like '/chunk_vendors.js' didn't exist in the server's root directory. One solution is to reference the variable LA-U:REQUEST_FILENAME. This is a lookahead variable that determines the final, 'ideal' value of REQUEST_FILENAME. The other solution is to do the rewriting in a per-directory (<Directory 'path'></Directory>) or .htaccess context.
  • Why didn't REQUEST_FILENAME return the absolute path to the file? According to the mod_rewrite docs, it looks like my RewriteCond statement was in a 'per-server' context, which occurs before the HTTP request is mapped to the filesystem. I think this means that it's at the root level of the httpd.conf file.

[darcydriscoll]

Doesn't look like any other server configuration needs to be done.

Currently, we push the user to /index.html when they get a URL that doesn't physically exist (e.g. /chatroom, or a random string of characters). But: the URI that the user sees stays the same, and vue-router uses that URI, not the page the user is pushed to! So, as long as we get things right logically, we're good.

This does mean we have to get things right logically though. So I'll add that to the to-do list.

[darcydriscoll]

Added a fade-in transition for the sign-in page. I won't be adding any more in this story, because I don't know how I want the app to fade between the sign-in page and the chat room page yet.

[darcydriscoll]

I extended the session lifetime to 72 hours. This lets users keep their nicknames around for longer without allowing trolls to hog nicknames for too long.

[darcydriscoll]

Working on simple PHP error handling and propagation to client. Some things to look into:

• Ensure I get all cases where a mysqli function quietly produces an error and propagate back to user (look in db function).
• In long-term: consider a mysqli wrapper class? For all function calls, we check if they produce a quiet error, and then transform that into an exception?
  • First, we would need to investigate how PHP errors and executions work in more detail. It's possible that I'm missing something major!

[darcydriscoll]

Whoops!

[darcydriscoll]

I've implemented rudimentary error handling such that most errors are propagated down to the client. Some things to refactor:

• Draw errors codes in .php and .vue files from the same source, maybe a .csv or .json? .csv is all we need really.
• Refactor code that transforms false outputs from functions into exceptions. Would need to investigate a good approach to this. PHP doesn't seem all that great at error handling? Also, I think I'm being a bit anal with it.

[darcydriscoll]

Working on standardising error codes. I've got it working on the server-side, now I'm working on the client-side.

It's more complex than I thought it would be. I guess I've never done this combination of array manipulation and file handling before. They're not areas that I'm especially competent in.

[darcydriscoll]

I've put some work into client-side error codes. Again, harder than I thought.

I need a way to prevent the SignIn component from doing anything before we've fetched the error codes and processed them. We could use .then and a data property to record when everything is loaded? Then, use that data property on the template to turn on/animate/brighten the sign in component when it hits true.

Or -- can we make use of await in Vue lifecycle methods? Anything else in Vue -- async components? <Suspense>?

[darcydriscoll]

Done! Added attributions as well.