| /** | |
| * The Anatomy of a Remix Route | |
| */ | |
| import { parseFormBody, json, redirect } from "@remix-run/data"; | |
| import { | |
| Form, | |
| useRouteData, | |
| usePendingFormSubmit, | |
| preload, | |
| } from "@remix-run/react"; |
Copyright © <year> <copyright holders>
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
| import Foundation | |
| extension Data { | |
| var prettyPrintedJSONString: NSString? { /// NSString gives us a nice sanitized debugDescription | |
| guard let object = try? JSONSerialization.jsonObject(with: self, options: []), | |
| let data = try? JSONSerialization.data(withJSONObject: object, options: [.prettyPrinted]), | |
| let prettyPrintedString = NSString(data: data, encoding: String.Encoding.utf8.rawValue) else { return nil } | |
| return prettyPrintedString | |
| } |
tl;dr I built a demo illustrating what it might look like to add async rendering to Facebook's commenting interface, while ensuring it appears on the screen simultaneous to the server-rendered story.
A key benefit of async rendering is that large updates don't block the main thread; instead, the work is spread out and performed during idle periods using cooperative scheduling.
But once you make something async, you introduce the possibility that things may appear on the screen at separate times. Especially when you're dealing with multiple UI frameworks, as is often the case at Facebook.
How do we solve this with React?
Via brew or other method
In order to work on every connection and on any TLD, dnsmasq needs to be the first DNS resolver receving the query.
And since dnsmasq is a local process, all DNS queries need to go to 127.0.0.1
On macOS, /etc/resolv.conf is automaticaly created, depending on a variety of things (network settings, etc), so it cannot be edited.
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
@kangax created a new interesting quiz, this time devoted to ES6 (aka ES2015). I found this quiz very interesting and quite hard (made myself 3 mistakes on first pass).
Here we go with the explanations:
(function(x, f = () => x) {
| // CS:GO "saved" player logic | |
| // based on the 20151008 version of the CS:GO Linux dedicated server | |
| // | |
| // reverse engineering by sigsegv | |
| // from x86 assembly to C++ with the help of a disassembler and the Source SDK | |
| // (please don't sue me) | |
| // terminology: | |
| // "enemy" player who was just killed by savior |