| // Playground link: https://www.typescriptlang.org/play?#code/PTAEHEEsGcBdQG4FMBO1IHsB2AuUALWWAB2hxAHMZYA6K2fAVwCMaBjDAW2ACUelkaVMABMAZgCMbMQDYAHAFZFAQwAmCkWwAMSACwB2VXJHN98hQu1IFAWABQ92AE9iSUAFEAHkjYAeAMJcnMpYqtAANKAAyrDKsG4AvKAA3qBwymwA1ngA2gC6kQA2GGzKhWQpAL6glQB8oAn2oKCBnMGh0KBInvEdoDmQWABmqC1BIaqRNNODIyig-HB5TaAA-B7efouwkV4+re2qvjFxSJEHE7W1K3gn8QDc9o4ubgDygiiQqki+r8wAVpEAHLKThnUAANTKjCQ9SSILBXR6SD6cE+WAoaxSKxyAGlQINQAAKTJIJwYIagP7-ACUoAAPqAEUg8nh8d1emEmaC3OsoYUYaA8NS8aAAGTE0nkynUmnLOzVPBYASoR4OOzOVwQJCwfkw34A4E8uHcxEclFcqUUqkArEi5l5IWgZWCNXPLUAFUYxEKPyBSM5nSwjE4zFQkR4AYtnRCTnyDX6eRNPByAHJfRiGKnHea+v71pG8F6fX7IjlY1Npjwk267IN4ighhk3ECkBQgSGwyhfABBZidXNc4Oh1D1VLKihxSDIPB9zqVd0ttu+D0mj1RvNtjsj7uzUZz+rrOdO9eDoOd0brVvti-d1dOl2qp4al6gOcrtcbrnX7dd3x7+Y53vI9+3XIsv3PHcsTA50VRQWtNTcHtiB9JwokgCgsBXSIAAUMAHZE+mYDAMF9EITTwgjA1AWAUEFdYYOvD8ENfcAdXQzCPwTU9CO-Ldb18Ycu0PUAm3KNw8FomEWK1ABZRhCg4rCe0iAAhE0chU0BVJzXjOhyKTwUMx1GRyMToHBcyWSxQynSsmS3CiENf1QXsIOdW81PcoTRwTHJphoYtfV7WpK0C71gvUvI0wzCgs0dCUfPg59EOiFggp+Ht3NjfIvLPUAcq |
Memoization is a somewhat fraught topic in the React world, meaning that it's easy to go wrong with it, for example, by [making memo() do nothing][memo-pitfall] by passing in children to a component. The general advice is to avoid memoization until the profiler tells you to optimize, but not all use cases are general, and even in the general use case you can find tricky nuances.
Discussing this topic requires some groundwork about the technical terms, and I'm placing these in once place so that it's easy to skim and skip over:
- Memoization means caching the output based on the input; in the case of functions, it means caching the return value based on the arguments.
- Values and references are unfortunately overloaded terms that can refer to the low-level implementation details of assignments in a language like C++, for example, or to memory
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
Тут перечислены не законы, последние слово всегда за здравым смыслом. Тут перечислены лишь направление, куда надо стремиться. Принципы, которые должны помочь, когда не знаешь, что выбрать.
- Пользователь. Если что-то сильно мешает UX или есть критическая ошибка, то в первую очередь мы спасаем пользователей. Для этого иногда надо взять ответственность на себя, переубедить толпу, написать плохой код.
В данной заметке рассматривается работа JWT с симметичным алгоритмом шифрования (HS256/HS384/HS512)
Аутентификация(authentication, от греч. αὐθεντικός [authentikos] – реальный, подлинный; от αὐθέντης [authentes] – автор) - это процесс проверки учётных данных пользователя (логин/пароль). Проверка подлинности пользователя путём сравнения введённого им логина/пароля с данными сохранёнными в базе данных.
Авторизация(authorization — разрешение, уполномочивание) - это проверка прав пользователя на доступ к определенным ресурсам.
Thanks everyone for participating in the quiz!
Many of you have posted correct answers.
What we know:
A top-level App component returns <Button /> from its render() method.
Question:
>What is the relationship between `` and this in that `Button`’s `render()`?
Английская версия: https://evilmartians.com/chronicles/bootstrap-an-intervention
У CSS есть несколько базовых проблем, которые позволяют очень быстро отстрелить себе ногу при неправильном использовании:
-
Глобальный неймспейс – в серверном программировании все что написано в файле, в файле и остается. Все же что написано в css и js засирает глобальное пространство имен со всеми вытекающими. В JS эту проблему сейчас побороли всякими модульными системами, а вот с css сложнее. В идеальном мире это должен починить Shadow DOM и настоящие Web Components, но пока их нет единственный способ с этим бороться – следовать какой-то системе именований селекторов, которая по возможности уменьшает и исключает возможные конфликты.
-
Каскадность – если на один элемент может сработать несколько правил, то они все и сработают последовательно. Если есть элемент
h1.title, на него сработают все правила для теговh1и все правила для класса.title. Так как весь html состоит из тегов, то правил которые п
| /* -------------------------------------------------------------------------- */ | |
| // All Bootstrap 4 Sass Mixins [Cheat sheet] | |
| // Updated to Bootstrap v4.1.x | |
| // @author https://anschaef.de | |
| // @see https://github.com/twbs/bootstrap/tree/v4-dev/scss/mixins | |
| /* -------------------------------------------------------------------------- */ | |
| // Grid variables | |
| $grid-columns: 12 !default; | |
| $grid-gutter-width: 30px !default; |