Недавно я начал строить большую социальную сеть, и я думал, что моя структура хороша, но оказалось, что я очень плохо построил эту логику.
Я смешал свои взгляды с AngularJS (плохая идея), пропущенное расширение лезвия, но поскольку я использую много блоков и боковых панелей, это стало болью в заднице.
В настоящее время я просто обрабатываю валидации формы с угловым, но на самом деле все страницы моего сайта потребуют ajax, потянув данные и т. Д.
Я искал вокруг сети, и я увидел, что угловые взгляды хранятся в общей папке, но поскольку все мои страницы будут использовать угловые, это хорошая идея сохранить все мои взгляды публично и просто использовать Laravel в качестве задней части?
Я знаю, что это глупый вопрос, но я немного смущен.
Любая подсказка подсказки оценивается.
Существует два способа объединения этих фреймворков:
Только визуализация на стороне клиента
Это более простой способ и используется большинством веб-приложений. В этом случае вы должны использовать Laravel в качестве конечной точки API, которая вернет JSON. Angular может запросить эти данные через службу $http или $resource и скомпилировать шаблоны, которые вы храните в общей папке. Угловые шаблоны – это просто HTML с директивами и некоторыми {{var}} операторами. Таким образом, Angular выполняет всю маршрутизацию.
Отправка на стороне сервера и на стороне клиента
Это труднее, когда Laravel выполнил маршрутизацию и скомпилировал некоторые шаблоны на стороне сервера. Вы использовали бы Angular только для некоторых взаимодействий на сайте таким образом, чтобы использовать jQuery, например. Преимущество такого подхода – производительность, так как пользователи получат полный HTML-код при первом посещении вашего сайта. Недостатком является то, что вам, возможно, придется дважды написать некоторую логику и не использовать некоторые функции Angular.
Чтобы на самом деле воспользоваться большинством функций углового, вы должны написать одностраничное приложение. Это означает, что вы будете общаться с сервером через веб-API, и у вас не будет шаблонов на стороне сервера Laravel.
Итак, да, вы должны написать два развязанных приложения. Одна клиентская сторона, использующая Angular и одну серверную сторону, которая предоставляет веб-API, предпочтительно RESTful.
Таким образом, вы можете переключиться с JS / HTML / CSS на стороне клиента на Flash или Silverlight или на что-то еще и с Laravel / PHP / MySQL на .NET или NodeJS или Meteor / MongoDB.
Серджиу прав, но в некоторых случаях Laravel по-прежнему предлагает преимущества, которые не могут быть достигнуты с помощью клиентских шаблонов. Это связано с SEO и WCAG (доступность).
AngularJS отображает контент посредством манипуляций с DOM, поэтому поисковые системы не могут определить, какой контент отображается после завершения этих манипуляций. Это также относится к устройствам чтения с экрана. По этой причине некоторый контент должен быть доставлен с помощью конструкций с видом на сервер. Вот почему WordPress и Laravel имеют длительный и здоровый фьючерс.
В фокусе или в тех случаях, когда SEO и WCAG не важны, шаблоны клиентской стороны с привязкой к данным, такие как те, которые используются с AngularJS и Ember, будут использоваться все чаще, поскольку все больше разработчиков узнают, как их использовать.
Что касается использования конструкций AngularJS или Laravel для представлений, лучше всего изучить, как использовать их и применять там, где они наиболее подходят.