If you're a resident of redux land, you've probably heard the tale of container components vs presentational components. The latter has no knowledge of redux, does the heavy lifting rendering wise, and communicates with the former via callbacks. The former knows about redux, state, actions, the store, etc. There's a clear demarcation between the two sides. That being said, sometimes you don't need presentational components. If the rendering is simple enough, you can "just do it". You hear a recommendation, guide line, or best practice suggested by a framework author, and over time you apply it rigorously; treating it as a fact of life. I'm guilty as well (although I go out of my way not to be). Ultimately you have to be pragmatic about how you apply idioms and best practices. Sometimes it's worth asking "does this really make sense". I found myself wondering just that when I was staring at a container component that was a mirror image of the present
| const flattenInternal = (input, initialDepth, acculamator = [], depth = 0) => { | |
| if (initialDepth !== undefined && depth > initialDepth) { | |
| throw new Error(`array has exceeded the target depth of ${initialDepth}.`) | |
| } | |
| return input.reduce((acc, value) => { | |
| if (Array.isArray(value)) { | |
| if (initialDepth !== undefined) { | |
| return flattenInternal(value, initialDepth, acc, depth + 1) | |
| } |
| ## To execute, install Ruby, download file, and run: | |
| # ruby mult-table.rb | |
| THREE_SPACES = ' ' * 3 # new String(' ', 3) | |
| def print_header(rows) | |
| print THREE_SPACES # Console.Write(...) | |
| 1.upto(rows) { |number| print "#{THREE_SPACES} #{number}" } # String.Format(...) | |
| puts # Console.WriteLine(...) | |
| end |
Yes...it's true...redux is smart....smarter than you even know. It really does want to help you. It strives to be sane and easy to reason about. With that being said, redux gives you optimizations for free that you probably were completely unaware of.
connect is the most important thing in redux land IMO. This is where you tie the knot between redux and your underlying
components. You usually take state and propogate it down your component hiearchy in the form of props. From there, presentational
I only had 45 minutes in total to finish the entire assessment, but this was question 5/6. I ran out of time before submitting my final answer (which I'm disappointed in). Once the challenge was over, I thought more about the solution to the problem and was able to figure it out. What made the challenge more tricky is that the input was coming in from standard input and being buffered via the data event. Seeing this in node just kinda freaks you out when you're racing against time. All you can think is 😳. The authors of the assessment were kind enough to register the required event handlers for accumalating the input, and even provided the location of where to act on the final, fully buffered version of the input (I believe this was the 'end' event). Yes, stdin is a stream in node, and as a result, an event emitter. I'd still have run out of time even if I were able to fully derive my solution, as this took me at least 20 minutes of heuristics with a clear head, after the fact. That's pretty shocking.
If you've ever worked with http in node what you quickly come to realize is that it's not all that straightforward. You'll be bold, at least initially. Like me, you'll go read up on the docs for the http module. You'll properly subscribe to all the right events like on('data), and feel good about yourself. But if you're anything like be, you're bound do this wrong at some point. You probably won't subscribe to all the right things in the right order. You might not properly buffer the response. You may just have a WTF moment in production on day that brings down your entire site (just like I did about 2 years ago). Whatever the case may be, I believe you'll ultimately just settle on using request as your go to for http. If you want a promise based variant then you might go with some wrapper library as well.
So, we know request is the hip way of doing HTTP in node. request is kool. It's got a ton of usage and it pretty
| import $http from 'http-as-promised' | |
| import Promise from 'bluebird' | |
| const resolveClass = (currentCount, { room, students, next }) => { | |
| const studentsTwentyFiveOrOlder = students.filter(({ age }) => age > 24) | |
| const count = currentCount + studentsTwentyFiveOrOlder.length | |
| if (next) { | |
| return $http | |
| .get({ |
Why...why are we here good sir? Well...I don't want to be here right now. I really don't. It's Saturday night, the Warriors beat the Clippers by the hair on the chinnies and dodged a late fourth quarter comeback, and I really want to eat. But...I have to blog. I have to do it now. If I don't, this story will not be the same. Why are we here? Because I'm on production support, that's why. I got an email from pagerduty that was like:
Unhandled rejection TypeError: next is not a function
I'm like huh? Wtf. What broke now? Why now? It's the weekend, I don't want to be here. I want to do me!!!!! But...I'm on production
Working with streams in node can be a scary and daunting task. The first time I saw the stream handbook, it left me quite perplexed. After seeing stuff like
through, through2, and @acrute doing some stream kung fu on the job, I knew it was time. Streams are actually pretty straightforward once you get the hang of things. Read the handbook
and the node docs and eventually your epiphany shall be born. I think one of the most confusing things for me was that Readable
streams are for reading values that are produced by you, while Writeable streams are for dealing with values that are to be
consumed by you. Say I wanted to put (write) some data from another stream into a file, and I wanted to take control of this process.
Or say I just wanted to log (write) the results of a stream to say the console. These would be prime for Writeable
| # https://docs.angularjs.org/api/ngMockE2E/service/$httpBackend | |
| ### @usage | |
| path = require './path' | |
| urlMatcher = path '/users/:guid/helloworld/:guid' | |
| phones = [{name: 'phone1'}, {name: 'phone2'}] | |
| $httpBackend.whenGET(urlMatcher).respond(phones) |