Welcome back 👋 Three weeks of JS Foundations taught me so much, not just about JS. Primarily I had to learn to pick myself up and dust myself off, then clean up my melted brains from the floor...
Summer really takes it's time in the UK, especially if you live in the north! But finally, the sun has come out. 🌞 The extra work in the garden has been a welcome relief from JS Foundations. The relentless pace of boot camp 🏃♂️ means there is little time to recover from one mind-blowing concept before being introduced to the next, headaches from learning are a real thing! So i was grateful that pumpkins 🎃 grow relentlessly and seem to outgrow their pots weekly. I also had really successful time seeding peppers this year so ended up giving away seedlings 🫑 ↔️ 🍅 I did get some tomato plants in exchange though. More plants to home, but the upturn in weather has meant many of my indoor plants have been re homed outside 🪴 In boot camp, everything started to feel a lot less conceptual and a lot more 'real world'.
Recursion isn't as scary as you think. Most people I know first encountered recursion on freeCodeCamp. I did, in the introduction to this blog recommend this resource (and still strongly do), but their introduction to recursion makes it a little more complicated than necessary. My advice would be to take a simple JS kata like factorial and try to replicate your solution using a recursive function. If you feel comfortable with recursion, then look up 'tail-end recursion', which removes the call stack build up and makes those recursive functions lightning-fast.
Pure functions make for complicated TDD. A pure function is one which won't modify or mutate any data outside it's scope. So the input data and everything outside of the function's scope should remain unaffected after it's invocation. This concept itself isn't complicated, but once you factor in TDD then you are back into the world of mock functions and I wish you luck! This is possibly still my weak link in JS, but I still have plenty of time to come back to it. Having said all that, I am becoming more and more friendly with jest and the procedural nature of TDD. It gives you absolute faith in the functionality of your code step by step. Also it requires an additional layer of planning, which creates far more robust, reliable code. I am certain than it will be no slower in terms of productivity as problems tend to be solved very quickly, due to the way TDD breaks coding down into small manageable and easily de-buggable problems.
Giving lectures where you are trying to explain the 'this' keyword looks really tricky as it renders the use of the word this redundant. The this keyword is implicitly bound to the object in which the method was invoked, which basically means that if you have a method which uses the keyword this, which is stored as a value within an object. When that method is invoked from within that object, the word this will be referring to that object. It means you can write functions using the word this instead of having to hard code each object's name into a function, thus making functions re-usable as methods within multiple objects. Object oriented programming seems relatively straightforward at the moment, compared to functional programming, but no doubt time will prove me wrong!
Classes, constructors and prototypes are better than factory functions. Classes brought with them one of the most fun couple of boot camp days so far. I was working with the legend Khizar, a knowledgeable and patient programming pair partner. Also we were using classes to build a Pokemon themed game, which pleased my partner as a childhood Pokemon fan and pleased me as an old-school gamer. Factory functions are the older way of using functions to build objects in JS. It allows you to build many objects using the same template, handy for example when building several Pokemon characters with similar attributes. The code when using factory functions isn't very DRY as there is tons of repetition. Fortunately classes and constructor functions do lots more for their money. They automatically create a new object and more important they create a prototypal link between the constructor and the object, meaning that any functions available in the constructor are also available in the created object, without the need to code the function in each object.
Promises and the return of return. After a few days living in the frustrating confines of asynch land and callbacks, it became clear that this is a massive part of living with JS. The only way to avoid blocking code (code which stops other code executing) is to take advantage of the event loop. Fortunately there is the newer JS method of using promises. These guys allow you to stop stacking up callbacks and instead return (yes we are allowed to return again) promises into another block depending on their state. Promises can be pending (awaiting response), fulfilled (they are sent to the next then block) or rejected (they get sent to the catch block at the end of the chain, which catches all errors). And promises can be easily returned to the next then block if necessary, for example if you are wanting to write some logic based on the return values of two separate promises. I imagine we will end up using promises more than callbacks, but there is still asynch/await to come so stay tuned...
Backend week, company presentations and cohort drinks. Will I be able to handle going out in public places again?