True, you can have as many divs as you want. But it can't be in a more sensible element and there is no good reason with today's CSS layout to want to put it in untold wrappers. Maybe it is a react thing where everything has to be in div wrappers.
Anyway, if the spec matters more than the toolchain it should not be anywhere but directly under the body element.
This comment breaks the site guidelines, which ask you not to insinuate astroturfing without evidence. Please don't post like that here; it's a toxic trope that people are nearly always imagining and projecting onto one another. Mind you, your post was far from the worst example of this—but it still needs nipping in the bud.
In this case, the history of the users commenting is enough to make it overwhelmingly unlikely that they were paid, and the well-known propensity of users to comment just on a title clinches it.
Sorry, I didn't mean to imply astroturfing. My comment is asking how many people "paid to read the article" (because it's behind a paywall), and not "were paid to comment here".
Still not a great comment I admit, but with the amount of discussion going on I would be surprised if everyone is subscriber or if they are going off of the headline alone.
Title should either reflect the original article or be amended to include "at some point in the future". FTA:
> Once we consider ESLint feature-complete w.r.t. TSLint, we will deprecate TSLint and help users migrate to ESLint; our primary tasks until then include:
> Continued TSLint support: The most important maintenance task in TSLint is ensuring its compatibility with new compiler versions and features.
> TSLint → ESLint compat package: Once the ESLint static analysis checks are on a par with TSLint, we’ll publish an eslint-config-palantir package, a drop-in ESLint replacement for our TSLint rule set.
`with` is an oddball. It's a macro but it's also a special form that has unique syntax that's not used anywhere else. It's basically the only variadic function in the language and it doesn't fit IMO.
It could have been implemented without needing the same special treatment with something like:
with do
x <- foo()
y <- bar(x)
z <- baz(y)
blah(z)
else
err -> handle_err(err)
end
with
x = foo()
y = bar(x)
z = baz(y)
blah(z)
else
err -> handle_err(err)
end
No do (uselessly verbose, it litters all the language) and = instead of <-
It should be normal code and take the else branch whenever there is any error, pattern matching included. The advantage is that the code can be indented in or out a with block, without any change. Much more convenient.
> In Elixir, we avoid using try/rescue because we don’t use errors for control flow. We take errors literally: they are reserved for unexpected and/or exceptional situations.
> No do (uselessly verbose, it litters all the language) and = instead of <- It should be normal code and take the else branch whenever there is any error, pattern matching included.
Using '=' insead of '<-' would break how with works. I can understand why one thinks the syntax looks weird. I avoid with when possible, but sometimes it's the easiest abstraction to use.
NGRX (the redux inspired state management library for angular) has a concept called 'effects', which lets you subscribe to the action stream (actions and the state in ngrx are both rxjs observables) and trigger side effects in response to certain actions. The effects themselves map to one or more actions (or zero if you want side-effects only) when they are finished that get dispatched.
Since you're dealing with them from within an observable stream you have access to all the rxjs operators, so you can do things like waiting for multiple actions to be dispatched before doing something, etc.
The biggest thing for me when trying to switch from console vim is `alt + <key>` will send ESC and the key, so you can use alt to exit insert mode and send a command at the same time. Doing alt+j or alt+k has become the way I always leave insert mode (or command, or visual).
Unfortunately most IDEs that have vim keybindings don't support this, and it has become such a baked in part of my muscle memory that it makes switching to anything else such a pain.
I'm a fan of TypeScript's structural typing for this reason. I can define an interface that describes the shape of a "plain old object" (it's fields and their types), and then write functions that accept/returns an object of that interface. What's great about structural typing is I don't have to explicitly say "create a new object of this type", any object that satisfies the shape of the interface is valid (object literals for example).
So you end up with the best of both worlds (in my opinion), where your state is made up of simple plain objects and you behaviors are just functions that accept simple plain objects, but you get all of the benefits of compile time static type checking because they are checked against the interface.
usb-c connectors are (8.4mm x 2.6mm) whereas micro-a is (6.85mm x 1.8mm) and micro-b is (6.85mm x 1.8mm)
It might just be a matter of simplicity, since USB-C seems to have a larger surface area for the spec, but I don't really know if that's the case.