#7 Programming, Scope and Contexts

One important thing to keep in mind while programming is scope, particularly when doing any sort of advanced programming. This is particularly important in JavaScript.

The JavaScript Closure Loop issue
The difference between let and var in ES6 and how to avoid problems. Of course you could always use let as the Stack Overflow post suggests in ES6, but as of May, 2017 let is not supported by IE or Safari. So unless you've got a fancy transpilation process (there will be a post about this... how to setup a proper Grunt + Babel + Browserify scaffold with a sample starter kit), var will be around for some time to come.
The issues around namespacing with JavaScript and why ES6 is such a huge improvement (or AMD or RequireJS). Specifically, why polluting the global namespace is horrible and why workarounds like (function () { // TODO }()) exist.
How to avoid problems with var by using the var that = this idiom, and how closures may lead to memory leaks (implementation dependent of course; I would not worry about such innane details unless it actually happened avoid premature optimization).

Of course those are all trivial problems that any JavaScript programmer is aware of. The sophisticated issue relates to templating and contexts, particularly when web programming. Take for example the following Handlebars template and code

{
  outerData: "Outer Data"
  innerData: [
    { text: "Inner Data" }
  ]
}

{{#each innerData}}
  {{> content }}
{{/each}}

{{> innerData }}

{{> innerData innerData }}

Do you know the difference between the last line and the second last line? One declares a partial given a context (even this can be used) and one does not. Which is appropriate for what situation? This is the Jedi mastery that a scope-aware person keeps in mind. Scope is also a computer science concept of course.

In particular, the first thing that I look at with a templating / binding system is how it handles contexts and whether it can nest 2 or 3 or n times deep.

Because for any non-trivial application, nesting of views and partial views is the main problem and issue at hand.

Comments

#6 - ES2015 / ES6, Grunt

Significant updates to my project over the past few days. Introduced grunt, modified all my JavaScript to use Babel + Grunt + ES6 style imports. All the JavaScript gets transcompiled to a dist/ directory, then the system gets executed through grunt. All works because all the paths are relative, and the correct files are copied over to the dist/ directory each time (also introduced a cleaning task). Basic stuff, but another pain that I wish I didn't have to deal with. The good thing is everything is setup on command line now, with rudimentary continuous integration (grunt watch) and a rudimentary build process. Introducing more and more utility classes, building out the foundation of the system... getting soon to the point where I can build out the system's widgets one-by-one, and hopefully my next post will be about rendering to the phone. Here's a portion of my Gruntfile.js in case anyone has trouble setting up their Babel + Grunt configuration... in particular, the key

#4 - Multi-File Configuration

Stopped counting the days, doesn't make sense with gaps. Trying to ramp up to many more hours a day. Eventually I will be successful. Dealt with the "partial configuration" problem mentioned in the last post. Won't post that because it's very custom. I just used a recursive function to parse the JSON and if the key started with a # sign, replaced the value with other JSON. { 'key1': 'value1', 'key2': 'value2', '#subconfig' : 'path\to\subconfig' } => { 'key1': 'value1', 'key2': 'value2', 'subconfig' : [ ... ] } However, I will post a class I wrote to deal with JavaScript type issues. Some basic stuff. Hopefully, it is useful to someone. Uses the new ES2015 class syntax.

#1 - The Beginning

April 23rd, 2017 Two weeks after quitting to pursue my own hobbies and the "dream" of running my own business or making my own product, I find myself looking back at work career with fondness. So many things have happened over the past few years, people I've met and things I've done, that it's hard to make sense of it all. But in the end, it doesn't really matter. The only thing that matters is how fast I can make what I want, before my cash runs out. Time is of the essence. Starts with a simple sketch, anyone can make it... data driven business application. Better not to be pretentious and call it "engine" or "framework" because it's going to be the smallest, tiniest thing I can possibly make that works end-to-end that I can build on and expand on. How long have I thought of making this? Many months, many years. Always thought of work, responsibilities, all excuses... could have stayed to make it, but there was never the urgenc

Brian's Dream

Search This Blog