Презентационни и логически компоненти

За изграждането на един продукт от 0 до 1, много рядко може да разчитаме само и единствено на собствен код. Започвайки да пишем уеб, мобилно или десктоп приложение, се нуждаем от някоя библиотека или framework. В следващите няколко абзаца ще разгледаме модел, който прилагаме при работа с Angular и React , като принципите остават валидни и в други случаи.

Защо правим нещата модуларни? Ако опитаме да сбием много функционалности в един клас, компонент и дори функция, това неминуемо ще доведе до проблеми с доразработването, поддръжката, тестването и „четенето“ от други разработчици. За да си улесним живота и да избегнем подобен резултат разбиваме всичко на отделни парчета или компоненти, иначе казано — правим нещата модуларни.

В Angular и React, терминът компонент е често срещан. И за двете технологии има style guides и препоръчани практики, които са там да ни държат в „правилния път“. А именно, какво е предназначението на тези компоненти, какво трябва да имплементираме в тях и как да ги свържем помежду им. С натрупването на повече код създаваме ситуация, която излиза извън контрол. Едно работещо решение, според нас, е разбиването на компонентите на категории. Нека ги наречем логически и презентационни (Container and Presentational). Казваме нека, защото може да ги срещнете и като “Fat and Skinny” или “Smart and Dumb”.

Какво са презентационни компоненти?

• Грижат се как изглеждат „нещата“;
• Могат да съдържат логически и презентационни контейнери;
• Могат да имат собствен DOM markup и собствени стилове;
• Консумират данни и инструкции, които не знаят от къде и как са предоставени;
• Не пазят данни вътрешно, освен собствено състояние.

Прилагайки този модел към Angular компонент, трябва да се стараем данните, с които работим, да не бъдат взети от service, а по-скоро от @Input променливи или такива, подадени през конструктора на компонента.
При React, консумиранитe данни се получават посредством ‘ this.props’ на компонента. Като добра, но незадължителна практика се счита презентационните компоненти да бъдат функции.

Какво са логически компоненти?

• Грижат се как работят „нещата“;
• Могат да съдържат логически и презентационни контейнери;
• Нямат собствен DOM markup и собствени стилове;
• Предоставят данни и инструкции на съдържащите се в тях логически и презентационни компоненти;
• Отговорни са за предоставянето, записването и пазенето на данни.

Това, че логическите компоненти могат да съдържат в себе си два типа, ги прави доста еднакви. Връщайки се отново към Angular и React, забелязваме, че в първия случай тези компоненти ще представляват „стандартните“ Angular компоненти, които консумират данни от services или друго. Разглеждайки ситуацията при React, се забелязват някои различия. Логическите компоненти набавят своите данни чрез различни външни библиотеки (Redux, MobX, т.н.). В тази статия няма да наблягаме на различните опции за извличане на данни, но за тези от вас, които са запознати с React и Redux , логическите компоненти са тези, които биват генерирани от higher order components или иначе казано са “connected”.

Какви са ползите от конкретния модел?

• По-добър “Separation of concerns”;
• По-лесно преизползване на презентационни компоненти, защото са агностични към данните, които консумират;
• Стиловете за презентационни компоненти могат да бъдат променяни, независимо от логиката.

Следва да си зададем въпроса: „Има ли негативи от използването на подобен модел?“. Краткият отговор е “Не, няма такива”. Ако трябва да отговорим по-обстоятелствено, то отговорът би бил, че има различни мнения по темата, а именно “кога” трябва да се въведат логически компоненти в едно приложение? Защо не може презентационни компоненти да си осигуряват данни сами, когато все още няма спешност? Добра практика e, моделът да се приложи още в началото, а не когато ни потрябва. В резултат на това решение, при разработване на нова функционалност, ще имаме основа от презентационни компоненти, върху които да стъпим. Практиката ни показва, че така поддръжката на презентационния слой е значително по-лесна.

Като заключение е важно да уточним, че основната разлика в тези два типа компоненти не е толкова техническа, колкото целева. Това са типове, които могат да взаимстват функционалност един от друг, ако се озовем в някои крайни ситуации. Понякога се налага да имаме презентационна логика в логическите компоненти и обратното. Затовa не се “връзваме” към този модел, а по-скоро се придържаме към него.