Last week after writing my update I thought I had the best idea - hey why don't I create an example page with my data grid in that I can show off to people, it should be great - nowhere near done, but great! That is where the pain truly began.

I think with every bit of coding I have done in professional and non-professional career I have hit that week - and I hope that people can relate with me here, where everything seems to be ending up at a complete and utter wall. Your code doesn't work and everything you search is not giving you any clue as to how to fix your problem and you realize that you have to do the worst thing ever - take time out of the project and do some research, where you most likely have to take ten steps back just to take two steps forwards - this for me is the fork in the road of the project all of those assumptions and blurry eyed quick things you did at the start come to bite you in the ass. Most importantly this for me is do or die time for many projects, and one of the reasons I wanted to start this blog, I wanted for once to do and not die.

So let me take you through some of the hangups that I have had this week, sit back relax and just take a trip.

Highlights from this week

• Created my first example with the project
• Started with network code
• Finally got npm test working

Things that could have gone better

• The time it took to learn the difference between CommonJs/AMD/UMD
• The time it took to fix most of the tests
• The time it took to finally decide to get rid of handlebars

Goals for this week

• Get the network code done
• Get some styling stuff and attribute stuff finished
• Start mapping out pager buttons

Amd vs CommonJs vs UMD

I had no idea this was a thing, as I said in my first blog post about my new side project I have not touched javascript in quite a while and when I do, I do it in a safe environment where people have already had to do the "hard bits" for me, set up the environment, setup the dependencies, and most importantly setup the build pipeline.

So from research this is my breakdown of these three technologies

• CommonJs
  • A way to include your javascript libraries when you are running in a NodeJs type of situation
• AMD
  • A way of including references when you are writing client side javascript libraries
• UMD
  • A way to compile down to a common language that work on both client and server side of the javascript ecosystem

Not surprisingly when talking about space UMD is the inferior option here as it has to be compatible with both programming models so it has to play nice with two ways of doing things and the more things you have to be compatible with the more code you have to write to be compatible (I'm sure Microsoft will tell you all about that). But even with that in mind, this is the way I have decided to progress with my application, why do you ask? No reason, I thought it would be cool if people could use this in both scenarios, before I was compiling down to CommonJs and this caused a lot of headaches.

Did you know there is no window.document in NodeJs
I know I there a lot of people yelling at their monitors, "of course there isn't, it's on the server, dummy". I sort of thought NodeJs would have mocked this out in some way and basically allowed users to store variables there, what this meant was that I was using JsDom to provide me with a fake window.document. Some very exciting news came of this (after 3-4 hours of researching) is that I no longer have to use this framework because I am compiling down to client side I can use the actual window.document which makes like so much easier!

Did you know that some libraries don't work/don't support UMD/AMD
LOOKING AT YOU HANDLEBARS
They seem to have a very long running issue on their most current version where their importing just fails when you are trying to use their library from a client side javascript file. This was a huge set back for me because I was hoping to use this to render all of my controls, now I have to use plain javascript, which I think will be slower once I get into very large data sets and javascript optimizations is not something I am particularly interested in.

Getting the tests to run

I discovered that I was basically testing everything the way that NodeJs wanted to test things that I wasn't using the dom what so ever, after some research I found Karma. Karma is a browser testing help that essentially allows you to test your javascript code in an actual browser.

I think the one thing I am missing (from the dotnet work) is to press f5 and you can just set a breakpoint and press f10 until the part your interested in comes up and then you can f11 for more in depth context. This does not seem to exist in the Javascript work (one of my many complains) because now I have to debug transpilled javascript, which is never a great experience.

Thanks to Karma I can now say that most of my tests work (I think as I write this that 2 of them are failing and hopefully I will get them working really soon) and it means that people can start actually collaborating on the project as they have a reasonable way of testing their code.

Closing thoughts of the week

It's been a productive week, which is weird to say seeing as I spent most of it on google, stack overflow and fixing tests but I feel like I've crossed the first major hurdle and am now in a position where I can sit down and just write tonnes of code and get it into a good place. I'm really hopping that by the next update I will have made some major, major strides into the code and can talk about some of the decisions I have made there. Stay tuned this is going to be good.

Project github page: https://github.com/joro550/bear-bones/tree/dev