Отправляя заявку в школу, я честно говоря, и ожидал знакомства с полным стеком БЭМа, т.к. для меня технология, в плане самостоятельного изучения, казалась несколько неподступной. И когда нам предложили самим выбирать технологии для проекта, я сильно не раздумывал. Так что не вижу ничего странного в том, что я изучал БЭМ в Яндексе =)
Да собственно ничего)
У меня есть сайт на angular работающий на данном способе. Но сейчас, с приходом react'а, я предпочитаю пререндерить страницу не только для SEO, но и для пользователей (что имеет свои плюсы). При этом например метод с _escaped_fragment_ не понимали боты соц. сетей и для них приходилось городить определение по user-agent'у на уровне nginx'a и перенапрявлять на тот же _escaped_fragment_.
В общем я за простоту, особенно если спека помечена как deprecated)
app.get('*', (req, res) => {
const memoryHistory = createMemoryHistory(req.url);
const store = initReduxStore(memoryHistory);
const location = req.url;
const history = syncHistoryWithStore(memoryHistory, store);
match({ routes, location, history }, (error, redirectLocation, renderProps) => {
if (error) {
return res
.status(500)
.send(error.message);
}
if (redirectLocation) {
return res.redirect(302, redirectLocation.pathname + redirectLocation.search);
}
if (renderProps) {
return fetchComponentsData(store.dispatch, renderProps.components, renderProps.params)
.then(renderTemplate.bind(null, store, renderProps))
.then(dataToServing => res
.status(dataToServing.status)
.end(dataToServing.html)
)
.catch(renderError => res.status(500).end(renderError.message));
}
return res.status(404).send('Not found');
});
});
Это позволяет держать всю логику наполнения стора в компоненте, хоть и по разному для клиентской части и сервера. Ничего удобнее я пока не видел, хотя хотелось бы конечно =)
Конечно, решит) Но все-равно не будет работать в IE < 11, что ограничивает круг использования.
Да и вообще, имхо, второе демо интересно лишь в роли демо как раз, в проектах бы я такое не применял… Для каждого слова по dom-элементу как-то черезчур)
Ко всему вышеперечисленному выше — я бы вынес загрузку данных в resolve роутов.
И тоже не особо понял чем не угодил в данном случае MySQL и почему ngAnnotate не справится с аннотированием. Со стандартными регистрациями angular'овских компонентов (и даже некоторых сторонних плагинов, например resolv'ы ui-router'а) он отлично справляется без дополнительной помощи. В свои компоненты, при использовании например $injector'a, да, иногда надо добавлять /*@ngInject*/
я так понял у человека index отдается phalcon'ом, и роутинг phalcon'а совпадает с роутингом фронта, поэтому так и выходит… Но вообще да, правильно на любой запрос вернуть index…
Т.е. вместо строк в crontab'e:
достаточно использовать:
У меня есть сайт на angular работающий на данном способе. Но сейчас, с приходом react'а, я предпочитаю пререндерить страницу не только для SEO, но и для пользователей (что имеет свои плюсы). При этом например метод с _escaped_fragment_ не понимали боты соц. сетей и для них приходилось городить определение по user-agent'у на уровне nginx'a и перенапрявлять на тот же _escaped_fragment_.
В общем я за простоту, особенно если спека помечена как deprecated)
и на сервере используется функция которая резолвит все dispatchOnServer компонентов:
При этом action'ы выглядят так:
Ее использование:
Это позволяет держать всю логику наполнения стора в компоненте, хоть и по разному для клиентской части и сервера. Ничего удобнее я пока не видел, хотя хотелось бы конечно =)
http://www.w3.org/Style/CSS/Planet/#item2
Да и вообще, имхо, второе демо интересно лишь в роли демо как раз, в проектах бы я такое не применял… Для каждого слова по dom-элементу как-то черезчур)
И тоже не особо понял чем не угодил в данном случае MySQL и почему ngAnnotate не справится с аннотированием. Со стандартными регистрациями angular'овских компонентов (и даже некоторых сторонних плагинов, например resolv'ы ui-router'а) он отлично справляется без дополнительной помощи. В свои компоненты, при использовании например $injector'a, да, иногда надо добавлять /*@ngInject*/