- Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
- pathname - The "file/directory" portion of the URL, like
invoices/123 - search - The stuff after
?in a URL like/assignments?showGrades=1. - query - A parsed version of search, usually an object but not a standard browser feature.
- hash - The
#portion of the URL. This is not available to servers inrequest.urlso its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things. - state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.
- pathname - The "file/directory" portion of the URL, like
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.
@broros
otherwise why would he hand over a popular package to a stranger?
If it's not fun anymore, you get literally nothing from maintaining a popular package.
One time, I was working as a dishwasher in a restu
| import {NetworkStatus} from 'apollo-client'; | |
| import get from 'lodash/get'; | |
| import React, {Component} from 'react'; | |
| import {Query} from 'react-apollo'; | |
| class Data extends Component { | |
| state = {refreshing: false}; | |
| onRefresh = refetch => { |
| // This is an advanced example! It is not typically required for application code. | |
| // If you are using a library like Redux or MobX, use the container component provided by that library. | |
| // If you are authoring such a library, use the technique shown below. | |
| // This example shows how to safely update subscriptions in response to props changes. | |
| // In this case, it is important to wait until `componentDidUpdate` before removing a subscription. | |
| // In the event that a render is cancelled before being committed, this will prevent us from unsubscribing prematurely. | |
| // We also need to be careful about how we handle events that are dispatched in between | |
| // `getDerivedStateFromProps` and `componentDidUpdate` so that we don't put stale values into the `state`. |
The proposal you’re about to read is not just a proposal. We have a working implementation of almost everything we discussed here. We encourage you to checkout and build our branch: our fork, with the relevant branch selected. Building and using the implementation will give you a better understanding of what using it as a developer is like.
Our implementation ended up differing from the proposal on some minor points. As our last action item before making a PR, we’re writing documentation on what we did. While I loathe pointing to tests in lieu of documentation, they will be helpful until we complete writing docs: the unit tests.
This repo also contains a bundled version of npm that has a new command, asset. You can read the documentation for and goals of that comma
No, this isn't about render props
I'm going to clean this up and publish it in my newsletter next week!
So react-i18n (not the npm one... one we made at PayPal internally) has this
| module type Promise = { | |
| type t 'a; | |
| let then_: ('a => t 'b) => t 'a => t 'b; | |
| let resolve: 'a => t 'a; | |
| let all: array (t 'a) => t (array 'a); | |
| let race: array (t 'a) => t 'a; | |
| let make: (resolve::('a => unit) [@bs] => reject::(exn => unit) [@bs] => unit) => t 'a; | |
| }; | |
| module Make (P: Promise) => { |
| import React from "react"; | |
| import ReactDOM from "react-dom"; | |
| import { fromPairs, map, pick } from "ramda"; | |
| /** | |
| * Wraps a React component into Angular component. Returns a new Angular component. | |
| * | |
| * Usage: angular.module('some.module').component('newAngularComponent', react2angular(MyReactComponent)) | |
| * (the usage is the same as in similar lib https://github.com/coatue-oss/react2angular) | |
| */ |
| // UPDATE: In 2023, you should probably stop using this! The narrow version of Safari that | |
| // does not support `nomodule` is probably not being used anywhere. The code below is left | |
| // for posterity. | |
| /** | |
| * Safari 10.1 supports modules, but does not support the `nomodule` attribute - it will | |
| * load <script nomodule> anyway. This snippet solve this problem, but only for script | |
| * tags that load external code, e.g.: <script nomodule src="nomodule.js"></script> | |
| * | |
| * Again: this will **not** prevent inline script, e.g.: |