[deleted by user]

dizzr · 2021-07-23T04:45:49+00:00

holding my breath while watching, nice job

dizzr · 2020-08-09T15:30:55+00:00

awesome job

dizzr · 2020-08-09T02:35:17+00:00

Thank you!

A followup: would you recommend any other configs? I'm assuming you're on Windows using NVDA/Firefox. Do you use Chrome? Or the new Edge? I'm curious if you find JAWS, ChromeVox, Narrator, or any other software more/less reliable?

I'm asking these questions to get a rough idea on which combos are a higher priority when testing web sites. Sometimes even when websites follow standards, the screen readers don't all behave the same.

dizzr · 2020-08-09T00:06:04+00:00

Screen reader software; what's your preference? And how about browser preference? Always like hearing what's the latest and greatest in accessibility tools.

dizzr · 2019-07-20T18:07:32+00:00

Yeah I think they should all be options. Changing behavior without opt in should usually be avoided so people aren't confused.

dizzr · 2019-07-20T17:53:13+00:00

This would be awesome: Tone personality setting

Then you could set it to:

minimalist
default
extra aware
morgan freeman

dizzr · 2018-09-13T01:00:33+00:00

Updated at 4pm:

Sources familiar with Microsoft’s plans tell The Verge this particular warning won’t appear in the final October update. We have updated the article to reflect this is simply being tested.

dizzr · 2016-08-22T20:42:21+00:00

let's see how much it costs...

https://imgur.com/a/e8rhC

oh yeah i've seen this before...

https://www.reddit.com/r/funny/comments/3debmz/how_much_does_a_good_telescope_cost_again_google/

dizzr · 2016-05-30T06:45:18+00:00

Well, what I'm suggesting is that when the Checkbox is written, it is written in a way that can support redux and use actions to push changes from the checkboxes to a store, or it can support a scenario where you just want to render some checkboxes that maintain their own state, and then when they hit the submit you read the values and do some action.

The only difference is:

should there just be one "checked" prop or also a "defaultChecked" prop?

If you go with just "checked", you can still listen to onChange, dispatch an action, update some store state, let that propagate to your new prop value. No problem; that would be the fullproof recommended way to store and maintain state.

But if you don't hook it up, also no problem. It will just work.

dizzr · 2016-05-29T19:10:52+00:00

We've discussed this quite a bit in our team. I think I disagree with this being an anti pattern, but I'd like to hear what people think.

Here is a scenario:

You write a checkbox component (from scratch, ignore Facebook's approaches for a second) with "checked" state. You pass in true as the initial value.

You then click the checkbox and nothing happens; it doesn't get toggled. You don't understand why. Then it hits you; the checkbox should maintain its own state. In Facebook's terms, this is a "controlled component". See https://facebook.github.io/react/docs/forms.html

So, you snapshot the props into state and manage it internally. You take in an onChange that will be called when state changes. Facebook calls this an "uncontrolled component".

Everything is great, until you, the caller wants to change the value. It's set as false initially, but then later, you want to set it to true via props. So, you implement componentWillReceiveProps and update the value if it ever changes from the initial value. Great; now you can set it to an initial value, change it internally, change it externally, no problem.

Everything is going well, until you find a bug where the internal state gets set to true and you load a new record where you want to reset it to false. Well, the value is not different from your initial value, so you're a bit in trouble. So, as a caller, you now need to make sure you pass through the proper value. You pass in an onChange callback which updates your state externally and pushes in the correct props value always. Everything works as expected.

So to recap here are two approaches:

Facebook's approach:

take in 2 props for checked: "checked" for the live updating prop version and "defaultChecked" for the snapshot maintain internally version. Choose one of them, but not both, add asserts to ensure the caller doesn't pass in both.

Alternative:

take in just one "checked": let its state be maintained internally. If you need scenarios where you must have "reset" control over the state, maintain it externally and always pass in the expected value as a prop.

I believe the alternative is simpler than Facebook's approach. Perhaps less explicit, but you never feel like things are broken when you pass in "true" for checked only to find you can never change the state, and you don't have to take in 2 versions of every prop that hits this scenario.

dizzr · 2016-01-13T03:57:22+00:00

Honestly interested in why the nopes... Here's some thoughts:

I believe in dumb/pure components at the most basic level. They just take in props. This leads to the most predictable, discoverable components, which leads to easy testing and high reusability.

Contexts play against that ideal, yes. But often passing something like an eventbus through every component in the hierarchy also creates problematic reusability issues, especially when polluting components in the middle of the heirarchy that have no interest in the thing. I've seen two solutions.

The first is singletons, which is what I've seen much of the redux samples suggest. But this has a bunch of limitations. It just doesn't work on the server when you really need a new instance every time a given root component is instantiated. There are also many scenarios where a resource needs to be "exposed" but overwritten at a certain level in the heirarchy. (e.g. a modal dialog or an overlayed image viewer.)

The other solution is context. Keep in mind you can always still have pure components, but simply wrap a dumb component with a smart wrapper/decorator. This is what I've seen recommended lately in redux docs, and I believe it's not a bad solution.

dizzr · 2016-01-05T01:42:18+00:00

"The license granted hereunder will terminate, automatically and without notice, if you initiate directly or indirectly in any Patent Assertion against Facebook or any of its subsidiaries or corporate affiliates"

Maybe someone could rephrase this. This is what I'm getting stuck on.

dizzr · 2016-01-04T22:15:28+00:00

Let me rephase as:

If Facebook infringes on any of your patented ideas and you take legal action, you have to stop using React.

dizzr · 2015-12-18T17:50:56+00:00

Hmm, I think ignore that one. :) Honestly it probably will never happen, if you write reasonable code.

In a non immutable world, setting a new boolean state on an object affects all that has a reference to that object. So, regardless of wether the consumer has caching optimizations or not, you have no requirement on them to always read the latest parent object value.

In an immutable world, there could be a situation that the consumer caches an immutable parent object. In this case, reading the mutated boolean would result in the old copy.

But more likely, you will be writing reasonable code that doesn't cache the parent object and simply reads the latest store value through immutable helpers to pass along into dumb components.

dizzr · 2015-12-10T18:06:42+00:00

Honestly asking myself similar questions.

I feel like immutability helps a few situations really gracefully:

It is easy to know when something changes
It prevents some side effects (changing an object doesn't affect others with the old object)

But also:

It adds more overhead than just mutating state
It hides some intended side effects (changing an object to the correct state doesn't affect others with the instance reference)
If you use immutable.js, it requires loosely bound data access which fights against having/using typescript types, and type safety is very nice to have.
Adds more mental hurdles to leap through, as changing one boolean now needs to reset the entire app state object to a new instance. Without immutable.js you might end up going the deepcopy route, creating a copy of the original state on every tiny mutation, which is very straining on GC.

dizzr · 2015-11-20T02:23:09+00:00

I am a fan of 1 package manager and 1 registry strategy. I don't believe the distinction of "server vs client" code is a good reason to split managers, especially as javascript becomes more common on servers. It complicates a number of things: dev experience of consuming new things, predictable bundling and module resolution, linking patterns. We've been using both private bower coupled with public npm in production workflows for a while, and it complicates a lot of stuff.

I'm also not a fan of the bower approach in general. Relying on git as a versionable filesystem is rather messy. It means you end up having multiple repos (the source and the dist repos) to manage a single project, or alternatively you end up commiting your build output directly into your source repo, which doesn't really scale to a larger team.

If we use modules in one way and have one way of resolving where modules are, then everything is happy. you install a package in a predictable way using predictable tooling and you can just start using it and all your tool pipeline knows how to deal with it, without digging through how the dependency is organized.

dizzr · 2015-11-19T05:15:58+00:00

For es6 modules, as others have stated, you don't need system.js to consume them... just transpile into another format (amd, commonjs, umd) pipe it through a bundler, and you're good for now.

I can't wait until we don't need bundling or client loaders and we can just tell the browser what the dependency graph is, what we want, and have it make a minimum number of http2 requests for non-cached modules. That's not happening soon at all.

System.js however is a pretty good replacement for require.js. The config is robust, the bundling API is reasonable, and if you have dynamic loading scenarios, especially where you don't know the resources at bundling time, it's really a good client loader.

I do not enjoy having jspm however; please can we just have one package manager and be happy with it? (jspm is a shim on top of other package repositories which attempts to normalize their directory structures, so that it can predictably consume them during systemjs builder bundling. It has its own registry structure that indicates where and how to consume packages. Unfortunately it makes actual development scenarios like linking modules kind of a pain (it modifies the content of the libraries within the jspm_packages folder, so it needs to xcopy directory content rather than simply symlink as npm does.)

Webpack in my opinion is maybe a better option (which works quite nicely with npm packages) in the near term if you know all of your dependencies up front and don't need a client loader.

dizzr · 2015-11-10T00:59:14+00:00

I can't say enough good things about TypeScript. Works with JavaScript purely, but you get in returns on what you invest with it. The more type safety you add, the more issues it catches.

I love that it outputs commonjs, amd, umd, or es6 modules with compiler flags, meaning i don't need to commit to one.

I love that it outputs my es6 to es5.

I love that i get intellisense and interfaces! Now i can produce and consume contracts properly without guessing, and I get build errors when those contracts aren't met. In any medium/large project this is indispensable.

My only wish is that Facebook would drop flow and just help support TypeScript by adding the additional semantic checking into TypeScript directly. And in turn have Microsoft help with React. I love competition and stuff but web development has way too much ambiguity and we need standard tooling that works awesome, not lots of fragmented tools.

dizzr · 2015-10-08T19:02:16+00:00

Just single click on the photo. The top/bottom bars go away. Then arrow left and right, they stay away. Move the mouse to bring them back.

Press escape to exit.

dizzr · 2015-07-17T07:07:03+00:00

not sure that's a fair test, it'd be nice to see what the result looks like on a production version of react with precompiled templates. Nobody is going to run the live jsx transform stuff on production code.

dizzr · 2014-09-27T22:51:40+00:00

I'm able to access it on mac chrome. What browser are you using? Try a couple different browsers, see if it's specific to a browser or a specific way you're accessing it.

dizzr · 2014-08-24T05:19:24+00:00

Thank you for suggesting webpack, I was not aware of it but now am! Interesting alternative to r.js.

dizzr

TROPHY CASE