Just you, your code and nothing else.... :meditatingbuddha:
I get these questions (or similarly-phrased questions) often enough that I figured it would be helpful to post my responses somewhere. So, uh, here you go.
Q: What changes did you see in the design process at Dropbox from when you started to when you left and how did that impact you as a designer?
A: When I first joined Dropbox, I was the latest in a team of about a dozen designers in a 400-person company. This small size allowed the whole team to critique one another’s work on a weekly basis, and frequently bother someone at their desk. By the time I left Dropbox, the company was almost 2,000 people, and the design team had grown to about 60 people (including product designers, researchers, content strategists, and illustrators). We went through a series of changes to adjust for our growth, but in the design team there were a few notable ones.
Good times. Here are the all the URLs to fill your tab bar:
http://swifteducation.github.io
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
| /* @flow */ | |
| var React = require("react") | |
| var Immutable = require("immutable") | |
| // In order to use any type as props, including Immutable objects, we | |
| // wrap our prop type as the sole "data" key passed as props. | |
| type Component<P> = ReactClass<{},{ data: P },{}> | |
| type Element = ReactElement<any, any, any> |
| * { | |
| font-size: 12pt; | |
| font-family: monospace; | |
| font-weight: normal; | |
| font-style: normal; | |
| text-decoration: none; | |
| color: black; | |
| cursor: default; | |
| } |
// please comment if you know of other BOOKS (not considering blogs just yet) on ES6 that are out or coming out
Hello, visitors! If you want an updated version of this styleguide in repo form with tons of real-life examples… check out Trellisheets! https://github.com/trello/trellisheets
“I perfectly understand our CSS. I never have any issues with cascading rules. I never have to use !important or inline styles. Even though somebody else wrote this bit of CSS, I know exactly how it works and how to extend it. Fixes are easy! I have a hard time breaking our CSS. I know exactly where to put new CSS. We use all of our CSS and it’s pretty small overall. When I delete a template, I know the exact corresponding CSS file and I can delete it all at once. Nothing gets left behind.”
You often hear updog saying stuff like this. Who’s updog? Not much, who is up with you?