alanreidt / range-slider-component

Realization of a range-slider component using Vanilla Javascript. Aimed skills: OOP, MVC, functional programming, Documentation, TDD, UML diagram, Airbnb style guide, etc.
https://alanreidt.github.io/range-slider-component/
MIT License
0 stars 1 forks source link

project structure #13

Closed alagunoff closed 4 years ago

alagunoff commented 4 years ago

Хм, очень непонятная организация веток и структура проекта. У тебя сейчас 2 ветки, с двумя разными демо-страницами, но по факту должна быть одна демо страница. Ты ее можешь сделать отдельной веткой, если хочешь, чтобы разграничить ядро слайдера, с демкой. А можешь оставить в ядре слайдера. Сейчас у тебя в ветке gh-pages, лежит вообще другой проект, как будто. Т.е. это не ветка от master ветки, а реально другой проект, с другой структурой и тд.

alanreidt commented 4 years ago

Так само предназначение ветки gh-pages именно в этом — содержание веб-страницы проекта. А следовательно, содержать в себе код другого проекта, косвенно связанного с тем, что в master ветке.

Я не стал ее размещать в docs папке master ветки, чтобы изолировать зависимости (в частности, bootstrap).

alanreidt commented 4 years ago

В общем, я решил все-таки упростить работу с демо страницей. Теперь она в папке docs находится. От test-page тоже решил избавиться.

alagunoff commented 4 years ago

В общем, я решил все-таки упростить работу с демо страницей. Теперь она в папке docs находится. От test-page тоже решил избавиться.

Отлично, в целом стало намного понятнее! Я вообще всегда за максимально простое решение любой проблемы, если оно конечно достойное, в то же время)

Я не стал ее размещать в docs папке master ветки, чтобы изолировать зависимости (в частности, bootstrap).

Получилось с этой проблемой разобраться?

Т.е. сейчас, как я понимаю, у тебя ветка gh-pages не задействована, а осталась только одна ветка master? Папку docs/src я бы перенес на один уровень с src и назвал бы одноименно demo-page. И уже в ней был бы файл index, который ты бы использовал в скрипте npm build и у тебя parcel собирал бы файлы в папку docs. Ну а в папке docs, можешь все в кучу свалить, а можешь оставить как сейчас, если хочешь чуть лучше структуру сделать)

alanreidt commented 4 years ago

Получилось с этой проблемой разобраться?

Да, все зависимости демо-страницы в devDependencies ушли.

Т.е. сейчас, как я понимаю, у тебя ветка gh-pages не задействована, а осталась только одна ветка master?

Да.

Папку docs/src я бы перенес на один уровень с src и назвал бы одноименно demo-page. И уже в ней был бы файл index, который ты бы использовал в скрипте npm build и у тебя parcel собирал бы файлы в папку docs. Ну а в папке docs, можешь все в кучу свалить, а можешь оставить как сейчас, если хочешь чуть лучше структуру сделать)

Тогда грань между ними потеряется. Сейчас же, есть Slider и демо-страница для него. Есть исходные файлы (src) для Slider'а и их production-ready версия — и тоже самое, отдельно, для демо-страницы.

alagunoff commented 4 years ago

Тогда грань между ними потеряется

Почему? Нет. Я не правильно объяснил выше. У тебя будет папка src в которой будет папка demo-page, core/components(или еще как, это будет папка для ядра слайдера). Ну и в папку docs будет собираться демо страница. Как по мне, хороший вариант. Ничего смешиваться у тебя не будет, за счет разделения по папкам в src. А сейчас, при взгляде в папку docs, там действительно все смешалось)

alanreidt commented 4 years ago

Почему? Нет. Я не правильно объяснил выше. У тебя будет папка src в которой будет папка demo-page, core/components(или еще как, это будет папка для ядра слайдера). Ну и в папку docs будет собираться демо страница. Как по мне, хороший вариант. Ничего смешиваться у тебя не будет, за счет разделения по папкам в src. А сейчас, при взгляде в папку docs, там действительно все смешалось)

Я про смешение между source и prod файлами говорю. Обычно source отражает то же самое, что и в prod, только в удобном для чтения формате. Твое предложение нарушит этот принцип — демо-страница будет болтаться в исходниках, хотя ее нет в production (и не должно быть. так как она второстепенна в рамках этого проекта).