TGIMBA .NET Core Upgrade – Vanilla JavaScript Login Page ‘Objectified’

Git  Code Commit (this and all commits back to my last blog post)

I was looking through the old The Globe In My BucketList Application (TGIMBA) registration code and I realized that I was not doing anything radically different with the Vanilla JavaScript client.

I was using native methods and nothing from JQuery, but it is still essentially the same old function based version as before. This kept bugging me since the whole point is to learn something new. To quote an co-worker from Chicago, ‘if you haven’t learned something new, what’s the point’?. Then it hit me…let’s use objects. I have been using JavaScript (in one form or another) for 15 years. With the possible exception of the Node JS Type Script Application Programmatic Interface (API) I did a while back for TGIMBA (but never used), it has been using this same function based approach.

As you can see from any of my previous JavaScript pattern posts (core project is listed as reference #1), objects are a reality in JavaScript. Slightly different that traditional Object Oriented Programming (OOP) techniques, but they are there. So, I decided to borrow the technique I used with defining an class (basically an object with properties and methods defined) and using it. More specifically, Object.Create(). It is one way to create an object based on another object.
1

To redo the login functionality, I defined a class for the Login Controller.  However, instead of an interface as described in the example above, I used a base class. For most controllers, a base object is more useful in my experience to hold common data points that all controllers share. First gotcha I encountered is that require() is Node JS construct. So, dropping the require() and module.export.X methods and then just creating the objects worked.

The new version looks like this:
2

I am not actually using the token property in BaseController.js, but I can.  As you can see, the property set in BaseController.js is present in LoginController.js.

6

I will most likely leave the token in the Session.js.  But common properties like this that are shared by the controllers would go here.  If I don’t end up using it, I will delete BaseController.js

Pros

  • Login_Login() becomes a little less confusing. I never really liked this naming convention, but I kept getting lost with all of the functions. With the object approach, its a little readable (I think)

410

Cons

  • Object definition and creation are combined. This is one thing I do not like about this method of JavaScript objects. Object.Create() aside, to create an object, there does not seem to be a separation between the definition and the instantiation.

7

  • EVERYTHING is public (as I understand it). There is not an easy way that is C#’ish to accomplish this. Reference #2 has some interesting ideas though. But they are more than I want to implement here.

Another change I am making. I really like the idea of doing meaningful unit tests on all relevant code. But I am really itching to get more of this project done and I keep getting stuck in plumbing issues (i.e. 2 months (ish) on figuring out the pipeline, month figuring out my production Angular environment, etc). So, I am going to remove the JSTest Vanilla JavaScript unit tests that already exist for code I convert to objects. There are some functions I will leave (i.e. Utilities.js, etc.) that I will keep the JSTest code for. Here on out, I am going to rely on the Selenium integration tests to cover all of the clients. Just for clarity though, if this was a production grade and not fun/learning project, I would be taking the time to continue with the JSTest code for all relevant code. Additionally, I would figure out unit tests for the other clients (i.e. Angular 6, JQuery and React JS).  This is done by adding the [Ignore] attribute to the MSTest in question.

5

I ended up creating an object for LoginController.js and ApplicationFlow.js.  I also added BaseController.js and RegistrationController.js objects (Registration.js is not functional yet).  So is the extra ‘object’ layer worth it? I honestly do not know at this point…but at least it is different and I am learning new stuff 🙂  Next post will be the registration page…really 🙂

Stay tuned!

References

  1. https://github.com/ehelin/JavaScriptAndStuff
  2. https://philipwalton.com/articles/implementing-private-and-protected-members-in-javascript/
  3. https://stackoverflow.com/questions/8215301/how-do-i-tell-mstest-to-ignore-tests-in-a-base-class-but-not-in-subclasses
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s