| export default { | |
| const parents = getNamedParents(this.$router.options.routes, this.$route.matched) | |
| if (parents.length) { | |
| return { | |
| name: parents[parents.length - 1].name, | |
| } | |
| } | |
| return { name: 'home' } | |
| } |
I've designed a lot of RPC protocols in my career. One pattern that's worked well basically goes as follows:
// Client calls: print('Hello World\n')
-> [1, "print", "Hello World!\n"]
// Server sends return value (or lack of return vvalue)
<- [-1]
// Client calls: add(1, 2)
-> [2, "add", 1, 2]
I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.
I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.
"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr
| // Don't forget to prefix your category! | |
| #import <UIKit/UIKit.h> | |
| NS_ASSUME_NONNULL_BEGIN | |
| @interface UIWindow (PSPDFAdditions) | |
| #if TARGET_OS_UIKITFORMAC |
This gist is a collection of common patterns I've personally used here and there with Custom Elements.
These patterns are all basic suggestions that could be improved, enriched, readapted, accordingly with your needs.
Chrome's profiler ("Performance tab) is very useful for measuring JavaScript performance, but what if you want to measure the performance of a custom extension?
For example, what if I would like to profile the following interaction:
| /** | |
| * First we will load all of this project's JavaScript dependencies which | |
| * includes Vue and other libraries. It is a great starting point when | |
| * building robust, powerful web applications using Vue and Laravel. | |
| */ | |
| require('./bootstrap'); | |
| window.Vue = require('vue'); |
| /** | |
| * Advanced Window Snap | |
| * Snaps the active window to a position within a user-defined grid. | |
| * | |
| * @author Andrew Moore <[email protected]> | |
| * @contributor jballi | |
| * @contributor park-brian | |
| * @contributor shinywong | |
| * @version 1.2 | |
| */ |
| /** | |
| * Advanced Window Snap | |
| * Snaps the Active Window to one of nine different window positions. | |
| * | |
| * @author Jonathan Coleman | |
| * @originalAuthor Andrew Moore <[email protected]> | |
| * @version 1.0 | |
| */ | |
| /** |
| # | |
| # Building V8 for alpine is a real pain. We have to compile from source, because it has to be | |
| # linked against musl, and we also have to recompile some of the build tools as the official | |
| # build workflow tends to assume glibc by including vendored tools that link against it. | |
| # | |
| # The general strategy is this: | |
| # | |
| # 1. Build GN for alpine (this is a build dependency) | |
| # 2. Use depot_tools to fetch the V8 source and dependencies (needs glibc) | |
| # 3. Build V8 for alpine |
