iqhater

"Хацкаем" метод метод, пишем в глобал результат, юзаем результат.

Math.floorOrig = Math.floor;
Math.floor = (n) => {
  window.num = Math.floorOrig(n)
  return window.num;
}

function getNum() {
  const num = Math.floor(Math.random() * 10);
}

getNum();

console.log(window.num);

Еще можно просто переопределить саму функцию.

function getNum() {
  const num = Math.floor(Math.random() * 10);
}

function getNum() {
  return Math.floor(Math.random() * 10);
}

console.log(getNum());

Добро пожаловать в дивный мир фронтенд фреймворков.
Поисковики увидят (гугл точно, но в целом с горем пополам), но если вам важна индексация, то вам надо осваивать SSR.

Попробуйте c# в смысле net core. Как по мне стройная архитектура и отличная ide покроет все остальные минусы. Все это ставится на самом дешевом линукс хостинге. Не студия конечно а сам проект. В связке с angular or react будет вообще супер. Впрочем я сам предпочитаю vue

Если вы действительно собираетесь писать все-все с нуля, то язык безразличен, и даже разница между Django и Laravel, в сущности, невелика.
Другое дело, что велосипеды сплошь и рядом не так эффективны и просты, как это кажется "на берегу". Поддержка их и добавление фич могут быстро оказаться дороже, а результат - хуже, чем использование готовых решений. А с ними, насколько я могу судить, у РНР получше, если речь о вебе и обычных для него задачах.
Особенно для новичков-велосипедистов, для которых открытием оказывается, что то, что они полгода лелеяли и изобретали из головы, имеет столько готовых решений...

Gopher (гофер).

Используйте Scss + переменные + формулы и все возможные продвинутые фичи + cборшик.
https://sass-lang.com/documentation/syntax

Вот крутой видос по теме: https://www.youtube.com/watch?v=Mrq2ora_p0o и крутой канал по верстке, там и бем видосы есть, но бем не панацея как по мне...

Мощь SASS/SCSS и владение сборкой, хотябы gulp в идеале webpack.

+ Уйма удобных плагинов для верстки и копирования кода для vscode
BEM Helper
eCSStractor for VSCode
Live Sass Compiler

Сейчас просто с космической скоростью можно работать с SASS/SCSS

Дело не в Angular, а в том что такое интерфейс. Я расскажу со стороны моей практики.

Интерфейс это контракт взаимодействия между техническими сущностями (классы, объекты, функции, и так далее). Если мы создаем 10 объектов, которые соблюдают (реализуют) интерфейс, значит их можно подменять друг другом (только не нужно нарушать LSP, это принцип SOLID).

Так вот, отсюда есть мощные бонусы:

Первое, если создавать интерфейсы, то сущности начинают зависеть не друг от друга, а от интерфейса. Это значит что вместо зависимости одного класса от другого конкретного класса, можно использовать зависимость от интерфейса и любой класс реализующий интерфейс. Таким образом, если понадобится, можно спокойно заменить один класс на другой, если они реализуют один и тот же интерфейс. Это называется принцип инверсии зависимостей (один из принципов SOLID).

Выходит что сущности не завязываются друг на друга, и их можно разрабатывать независимо друг от друга, а в разработке чем меньше связей между классами/объектами, тем лучше. Если потом понадобится изменить код, поменять класс, будет значительно меньше проблем. Меньше, потому что если есть цепочка зависимостей, то нельзя изменить что-то одно, потому что другое сломается, и придется менять всю цепочку. Убирая прямые зависимости изменение кода становится проще.

Второе, это стабильность, лично для меня. Я работаю на TypeScript, и там можно описать интерфейс, сигнатуру функции, и ожидать на входе любые данные, которые его реализуют, и вообще пофигу откуда они, но пока они реализуют интерфейс, всё будет работать стабильно.

Третье, это понимание с чем ты работаешь. Когда есть интерфейс, ты всегда понимаешь что можно использовать у объекта, что там есть, и какого это типа. Просто очень удобно.

Ну и самое главное, лично для меня, это то, что мы инженеры, т.е. мы должны проектировать систему, а потом реализовывать, и интерфейс это один из наших "чертежей".

Ты сначала думаешь как оно будет работать, какие есть данные, потом описываешь это через интерфейсы, и прочее, а потом реализуешь. Поэтому можно считать что интерфейс это один из ключевых строительных блоков архитектуры приложения. Без него сущности будут пытаться дергать нужные им данные от объектов на входе, без понимания можно ли их вообще оттуда дергать, что там вообще реально есть, и в итоге получится хаос.

Поэтому Ангуляр собственно не причем, это просто фреймворк, а принципы проектирования там те же самые, как и в любом другом приложении.

Выполнение функции f() завершается после первого panic, потом отрабатывает defer.
Второй panic выполнен не будет, т.к. выполнение функции уже завершилось и до него очередь не дойдёт.
Можно добавить немного log.Println в ваш пример и проследить ход выполнения, например вот так

package main

import "log"

func f() {
  defer func() {
    if r := recover(); r != nil {
      log.Printf("recover:%#v", r)
    }
  }()
  log.Println("Start first panic")
  panic(1)
  log.Println("After first panic")
  panic(2)
  log.Println("After second panic")
}

func main() {
  f()
  log.Println("After f()")
}

Вывод будет таким

2020/07/20 23:14:07 Start first panic
2020/07/20 23:14:07 recover:1
2020/07/20 23:14:07 After f()

Хотят тут многое зависит от нужной анимации

• Если какой-то элемент нужно использовать больше одного раза — делайте отдельным компонентом
  
• Если ваш родительский компонент очень большой — разбейте его на несколько компонентов поменьше, чисто для удобства
  
• Если вы предполагаете, что какая-то часть вашей программы будет часто изменяться — выносите в отдельный модуль.
  
• Если у вам большой кусок статического контента — выносите в отдельный компонент
  
• Если какой-то элемент имеет в себе очень сложную или затратную по времени логику — выносите в отдельный компонент.
  

Вообще, я стараюсь делать много мелких компонентов. Мне так тупо удобнее. Но главное без фанатизма. Вам не нужен отдельный компонент на каждый инпут, разве что у этого инпута должна быть какая-то инкапсулированная логика или оформление.

Когда вы его получаете - это время его создания. Далее, перед оправкой находите разность между текущим временем и временем его создания.

А можно и не проверять время жизни токена. Просто если в ответе сервера получили ошибку -
if (err.response.status === токен экспайред ....
- получаете новый при помощи рефреш токена.

Это же все относительно. Кто-то работает быстрее кто-то медленнее. Это ваш темп, если вы помимо решения задач еще и будете грузиться скоростью - на пользу не пойдет. Ну зафейлили значит зафейлили, кто сказал, что сроки были корректные.

Возможно вам стоит обудмать зачем вы работаете, если нет глобальных целей (аля накопить денег на машину или построить дом) то сложнее заставить себя работать.

Это можно представить как аналогию с другими языками:
Классы
Namespace

Суть одна, сгруппировать код выполняющий одну задачу и отделить его от остального кода для удобства поддержки.
Например пакет net/http позволяет работать с http протоколом. encode/json, c json форматом и т.д.

Судя по приведённой в комментариях ссылке, там используется bearer-аутентификация.

Получив token после авторизации, передавайте его в заголовках запроса в виде:
Authorization: Bearer awesome-token-12345

Именно так сервер поймёт, от кого именно идет запрос
https://swagger.io/docs/specification/authenticati...