JS фреймворки и тупик в развитии навыков?

Question

[Kostya_S]

Здравствуйте.

Объясните пожалуйста, как разрабатываются обычные сайты (не распределенные приложения) с использованием JS фреймворков?

На примере сайта по аренде квартир, агрегатор оъявлений.
Функционал стандартный для подобного рода сервисов:
Фильтр (район, комната/квартира, 1к/2к...)
Объекты на карте с информацией по объекту
Каталог с объектами с подгрузкой, есть отдельный блок где указано, что есть новые объявления но они пока скрыты и будут доступны через N часов
Есть поля с live поиском, когда вводишь и выдает варианты, отмечаешь нужные и они попадают в поле в виде тегов которые можно удалить. (как тут при создании вопроса)

Как разрабатываются подобные сервисы?

Например я сверстал каталог - как мне сделать подгрузку новых объектов и блок где написано что есть N кол-во новых объектов? Тут ведь явно видно, что нужны запросы к серверу. А сайт еще только на этапе верстки. Хочу заметить, я имею ввиду именно динамическую работу таких компонентов еще на этапе верстки.

Или пример с объектами на карте. Например если информация об объекте приходит динамически при клике на метку, вот откуда приходят эти данные, пусть даже фейковые, в каком виде я должен отдавать подобную работу прогерам?

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

Если я возьму Vue.js (изучаю пока основы), напишу на нем весь этот динамический функционал. Как я могу быть уверен, что я сделал правильно и программистам или мне не придется переписывать? Может им вообще этот JS фреймворк не нужен.

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

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

Comments

[sim3x]

так жс изучен уже или нет?

[Kostya_S]

sim3x: тоже в процессе, но от этого понимания не прибавляется

Answer 1

[Stalker_RED]

Либо вы используете какую-то заглушку вместо бекенда либо работаете в связке с человеком умеющим бек, либо становитесь немножко fullstack (что бы это ни значило), либо говорите "мне это не по силам".

Comments

[Kostya_S]

Stalker_RED

либо становитесь немножко fullstack

минимальные требования какие?

[Kostya_S]

Stalker_RED и что за заглушки?
фраза "мне это не по силам" не для меня, я не для этого пришел в эту сферу ) 2 года тут варюсь, хочется дальше двигаться

[Stalker_RED]

Kostya_S: В простейшем случае вам понадобится суметь написать несколько строчек кода, которые отдадут данные на клиент. В простейшем случае:

<?
header('Content-type: text/html; charset=UTF-8');
echo '{
  "foo": [
    {
     "customerID": "9936",
     "name": "bar",
     "hello":"world"
    }
  ]
}'?>

[DevMan]

Stalker_RED: тогда уж лучше отдавать json в заголовках ;)
а вообще есть куча инструментов для эмуляции api-сервера.

[Kostya_S]

DevMan Можно подробнее про json в заголовках?

Вот есть такой пример codepen.io/Siteacademy/pen/GZQWqy
Тут массив articles задан жестко в коде, но на реальных проектах я так понимаю в ключи данные подгружаются динамически?

[DevMan]

Kostya_S: > Можно подробнее про json в заголовках?
в приведенном выше примере лучше использовать application/json вместо text/html

> я так понимаю в ключи данные подгружаются динамически?
верно, подгружаются с сервера по мере необходимости.

Answer 2

[Vlad Feninets]

на начальном этапе в кач-ве бека можно использовать https://github.com/stympy/faker в связке с https://github.com/typicode/json-server

будут вам мокапы, которые будут выводить какие-то данные, когда появится бекенд - завяжитесь уже на него.

Answer 3

[unclechu]

Вам нужно "мокать" данные от сервера, т.е. вам нужен некий временный http-сервер, который по указанным роутам просто отдаёт содержимое статических json-файлов. У вашего front-end приложения должен быть локальный конфиг, где указан путь до бекенда, туда, на момент разработки, вы подставляете свой псевдо-сервер, напр, http://localhost:9000/api, если вы используете webpack для сборки, то можно приспособить для этого webpack-dev-server, на своём опыте я так и делал, см. https://webpack.github.io/docs/webpack-dev-server.html, написав хэндлер определённого роута можете описать простую логику раздачи json-файлов или поищите готовые рецепты такого подхода. Можно описывать дополнительно в отдельном документе какой роут какого рода информацию должен отдавать для последующей передачи её бекендщикам для реализации в уже реальной серверной части.

Answer 4

[McBernar]

Подобное не делается последовательно.
Вам нужно точно понимать — какие данные и в каком формате вам будет отдавать бекенд.

Answer 5

[Anton fon Faust]

Используйте какой-нибудь baas, например, rapidApi, backendless или firebase.

Answer 6

[Михаил]

Мне кажется многие вообще не поняли проблему и пытаются дать советы как сделать заглушку для json. Сейчас бы решать проблемы с заглушками...

Автор, как я понял, хочет понять как сдавать верстку которая требует динамического интерфейса.

Случай №1.
Автор берет абстрактный vue.js и лепит интерфейс и ... заглушку, конечно :)
Заказчик получает чек на некую сумму куда будет включены часы работы над интерфейсом. Довольный заказчик идет нанимать программистов, а те смотрят на него как на дурака и говорят что на vue.js уже давно никто ничего не делает и предлагают использовать модный-молодежный ХХХ фреймворк. Понятно что ситуация из учебника.
Случай №2.

Автор делает заглушку... нет, не ту заглушку которую тут все хотят сделать. А заглушку в самом интерфейсе, без логики. Остается вопрос как сделать верстку для динамических частей. Это, собственно, и спрашивал автор.
Заказчик в этом случае получает почти готовую верстку, но с некоторыми особенностями. Вполне приемлемый вариант.

Случай №3.
Автор находит компаньона и предлагает новую услугу: верстка + программирование интерфейса. Этот вариант выглядит наиболее оптимально с моей точки зрения. Все хорошо, все довольны.

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

В общем, я бы посоветовал найти партнера.