Андрей Титов

Установить prop-types и следовать инструкции: https://ru.reactjs.org/docs/typechecking-with-prop...

class Hook {
  protected $callbacks;

  public function __construct($callbacks = []) {
    $this->callbacks = [];

    if (!isset($callbacks) || !is_array($callbacks) || sizeof($callbacks)) {
      return;
    }

    foreach ($callbacks as $k => $v) {
      if (!is_string($k) || !isset($v) || !is_callable($v)) {
        continue;
      }

      $this->callbacks[$k] = $v;
    }
  }

  public function add($key, $callback) {
    if (!isset($key) || !isset($callback) || !is_string($key) || !is_callable($callback)) {
      return;
    }

    $this->callbacks[$key] = $callback;
  }

  public function remove($key) {
    if ($this->exists($key)) {
      unset($this->callbacks[$key]);
    }
  }

  public function exists($key) {
    return isset($key) && array_key_exists($key, $this->callbacks);
  }

  public function run($key, ...$args) {
    if ($this->exists($key)) {
      $func = $this->callbacks[$key];

      if (!isset($args) || !is_array($args)) {
        $args = [];
      }
      
      if (isset($func)) {
        $func(...$args);
      }
    }
  }
}

$hook = new Hook();
$hook->add("my_hook", function ($args) {
  // todo
});

$hook->run("my_hook");
$hook->run("my_hook", 1, "string", true);

Что-то вроде такого?

Есть стандартный фильтр blocklayered, который генерирует ссылку в зависимости от заданных условий.
По этой ссылке можно вывести любой перечень товаров.

• Бэклог продукта "GitLab Enterprise Edition"
  
• Бэклог продукта "YouTrack"
  

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

Плюс к сказанному, Inline стиль имеет самый высокий приоритет, игнорируя CSS правила, распространяющиеся на родителя и одноименные элементы/классы. Считается порочной практикой использовать инлайны в продуктиве, т.к. это усложняет поддержку проекта.

То же самое можно сказать про значение "!Important" в свойствах CSS.

сопровождение - новые фичи

Информационно-техническая - вам задают вопросы по документации на ваш код, советуются в том или ином плане.
Сопровождение - решение проблем с проектом.

(Моё мнение)

Вообще то product manager отвечает за всё что касаться продукта (любого продукта который он взял для разработки софт, моб. приложения, и д. ) его работа являться в умелом распределения человеческого ресурса для достижения результата он тот чел который соединяет куча народу и распределяет для каждого или группы людей задачи и контролирует выполнения этих задач с получением результата. Хочет менеджер дать совет по продукту это его дело ему же отвечать перед заказчиком или директором предприятие но это недоверия к своим людям а это порождает несамостоятельности единиц в целом что не оч хорошо на продуктивности.
-у меня скрипт не работает хр хр хр дай я делаю буду.
-а как мне страницу оформить хр хр хр даи я подумаю.
Он обязан разбираться и понимать как это кухня работает но вот варить резать жарить подавать оформить это надо распределить и контр. выполнения а не за каждом потереть и выполнить . А для чего нужен Менеджер (зарплату получать) качественно выполнить проект в ограниченное время!.

С моей точки зрения продуктолог (читай менеджер проекта) должен заниматься всем, что не описано в бизнес-процессе, не понятно исполнителям, имеет двойную трактовку. Он должен ставить задачи так, чтобы время вопросов от исполнителей по ним было минимальным, срок реализации предсказуемым, риски по этой реализации максимально учтены.

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

rm -rf /data/db/mongod.lock
mongod --dbpath /data/db --repair
mongod --dbpath /data/db

после первого шага УБЕДИТЬСЯ что mongod.lock удален, иначе успех операции не гарантирован :)

Действительно, скорее всего это про организацию кода.
Если мы делаем наше react-приложение возможно, что однажды нам придётся изменить хранилище. Вообще дурной тон использовать dispatch в самом компоненте не обернув его в HOC. Ведь это сразу делает невозможным переиспользование. Например у нас есть компонент, который рендерит какой-то список и использует redux. Для того, чтобы мы могли его переиспользовать правильно сделать так:

import React, { Component } import 'react';
import List from './List'; // Список
import { connect } from 'react-redux'
import { mutatinList } from './actions'; // Какой-то action

class ListContainer extends Component{
	render(){
		return(
			<List {...this.props} />
		)
	}
}

const mapStateToProps = (state) => ({
    list: state.list
})

const mapDispatchToProps = {
	mutatinList: mutatinList
}

export default connect(mapStateToProps, mapDispatchToProps)(ListContainer);

Если мы захотим переиспользовать наш спискок то нам не придётся переписывать сам компонент, а можем лишь написать новый HOC

Ещё по этой теме я написал небольшую статью

Тоже страдаю от этого вопроса. Лично мне, наоборот, не нравится что логика выносится в экшен креэйторы. Саги как то больше подходят.

Я бы сказал, что redux-thunk, redux-saga или какое-то другое "решение" для организации сайд-эффектов не является необходимой зависимостью для любого приложения, написанного на reactjs.
Точно так же как и не является необходимостью сам redux. Но если ваше приложение нуждается в инструменте для управления состоянием(redux), то автоматически из этого следует, что оно так же нуждается в инструменте для организации сайд-эффектов.

В redux-thunk вы диспатчите функцию словно это action. Это очень важно. В контейнере вне зависимости от "природы" экшена, вы будете писать this.props.dispatch(whateverAction).

А ваш коллега, напротив, будет вынужден синхронные экшены диспатчить через this.props.dispatch(syncAction), а асинхронный просто вызовом функции, содержащей setTimeout.

Как-то не очень красиво, да и самому контейнеру не обязательно знать какие экшены синхронные, а какие асинхронные.