Pull to refresh
-29
@MaZaAaread⁠-⁠only

User

Send message
Вы можете отрицать и делать вид, что проблем ООП не существует сколько угодно, но это не решение проблемы.

Так их реально не существует. Вы сами себе их придумали.
Те кто пишут код после меня не страдают, а разделяют такие же взгляды и понимают подход, нас таких много :)

Сочувствую работодателю вашему)
Сложно не заметить общую тенденцию в React по движению в сторону ФП. Но вы обвиняете всех вокруг в некомпетентности.

Есть люди которые думают своей головой, я как раз к таким и отношусь, а не поклоняюсь в слепую тому, куда движется технология Х или куда сказал Вася Пупкин.
У вас не закрадывается мысль что это вы что-то упускете, а не все остальные (включая разработчиков Facebook)?

Нет, я то как раз ничего не упускаю, от слова совсем. Я использую JS на 100%, в отличии от некоторых. Для меня нету авторитетов и авторитетного мнения, для меня есть только реальность, здравый смысл, читаемость и понятность кода.
У чистых функций слишком много преимуществ чтобы я мог перечислить их здесь, к тому же вы все-равно не поймёте.

Ахахаха, ясно. Вот вы реально сектант, жесть :D
Да я фанат иммутабельности, но в первую очередь чистых функций.

С вами все понятно)) Искренне сочувствую тем, кому достается ваш код) Хотя, наоборот это же подарок, проект на переписывание с нуля)

но мутабельность и классы, ООП там где оно ни к чему

С чего это вдруг они ни к чему?? Они ещё как к чему как раз таки.
несут за собой недостатки с которыми мне бы не хотелось мириться

Это ещё какие недостатки? Только пожалуйста реальные, а не выдуманные, теоретические и т.п.

Я не говорю что MobX это плохо всегда

Это не плохо никогда, от слова совсем. Без шуток. Разве что в вашем выдуманном мире, где кроме никому не нужных чистых функций ничего не существует)
Так вот именно, MobX это про мутабильность. Если иммутабильный фанатик, вам не сюда)

Вот же, элементарщина:
codesandbox.io/s/dreamy-fermi-yx3c7?file=/src/App.tsx
Так уже давным давно (ещё в 2016 году) все уважающие себя разрабы используют React только в связке с MobX'ом, и жизнь у всех на порядок легче поэтому. Или в 2021 году вы не знали об этом?

Очевидно что голый реакт это убожество, реакт + редакс — убожество в квадрате, единственный вариант это реакт + mobx, тогда все недостатки сходят на нет.

Впрочем, сами разработчики Facebook в некоторых статьях признаются, что часто могут отказаться от понимаемого кода во имя минимизации строк, например.

Это говорит лишь о том, какой лютый говнокод они пишут. И насколько они некомпетентны в профессии. Ставить экономию на кол-ве символов выше читаемости кода — абсурд.
Ясно, конкретный кейс вы разумеется не приведете, потому что его нет. Очередные пустые слова, основанные на «я где-то читал, кто-то обмолвимся и т.п.» не имеющие отношения к реальности.
Собственно одна из особенностей MobX заключается в том, что он также не имеет инструмента для control flow =) А вот эффектор лишен этого недостатка.

Конкретный кейс пожалуйста приведите, дабы не быть голословным где все рушится и нам ничего не остается кроме как использовать Effector. Вдруг и правда все так плохо и придется переходить на него.
И еще добавлю про саги — это как раз еще один костыль для редаксом, который дает ему возможность контролировать flow.

Более-менее жизнеспособное использование редакса строится именно из таких костылей. Саги — для control flow, селекторы — как замена всяким компьютедам, тулкит — как абстракция для некоторых продвинутых возможностей и фиксинга бойлерплейта.

Сам по себе редакс — просто очень примитивная технология без всего этого.

А можно просто не страдать фигней, переместиться в наше время и использовать MobX, жизнь станет на порядок проще, код станет на порядок лучше.
Относиться к SOLID можно по-разному, можно вполне себе без него жить, но с ним, по моему, легче.

SOLID усложняет всё очень сильно, при чем на ровном месте. Любая элементарщина становится очень громоздкой и сложной. Как минимум его использование на фронте тотально не оправдано, от слова совсем и несет только серьезный ущерб проекту и колосальный ущерб времени.
Чем плох коннект к глобальному объекту?

Ничем, от слова совсем. Реально, без шуток. Потому что ему нужен глобальный стор, без него он бесполезный, вот прям совсем бесполезный.
Чем вообще плохи глобальные переменные?

Ничем, от слова совсем. Реально, без шуток.
Код становится более жестким, не получится использовать модуль в другой ситуации, и прочая и прочая.

Кто сказал что вы каждый компонент/модуль будете переиспользовать где-то, когда-то потом, но прямо сейчас этого точно не надо? Вы тратите 100 условных единиц времени сверху, на ваш гребаный SOLID и прочую чушь в стиле, а вдруг он будет переиспользоваться где-то и т.п., но по факту экономите 2-3 условные единицы времени в реальной жизни, потому то ваши притянутые за уши ситуации настолько редко встречаются и настолько просто решаются, что ими вообще можно принебречь и в сухом остатке:
— Вы тупо прожигаете время в пустую.
— Пиши очень много лишнего кода.
— Делаете код очень запутанным.
— Повышаете bus фактор на проекте до максимальных величин.
— Фикс элементарных багов теперь съедает сильно много времени.
— Добавление изменение фичи теперь съедает сильно много времени.

И зачем всё это? Ради чего? Вот реально все только хуже хуже и хуже становится, сами себе веревку на шее завязываете, более того остальным мешаете навязываю свою «архитектуру», а потом меняете место работы и вуаля, образуется сразу же труп который переписывается с нуля.
так мобыкс простой и без философии или таки нет?

Простой, action/runInAction это грубо говоря транзакция. Их есть смысл использовать только когда сразу несколько реактивных переменных меняешь. В остальных случаях без разницы, хочешь заворачивай, хочешь нет.

import { autorun, observable, runInAction } from "mobx";

const counter = observable({ count: 1 });

autorun(() => {
  console.log("count is:", counter.count); 
});

counter.count++; // count is: 2
counter.count++; // count is: 3
counter.count++; // count is: 4

runInAction(() => {
  counter.count++;
  counter.count++;
  counter.count++;
});

// count is: 7


Вот и вся разница. codesandbox.io/s/sharp-tereshkova-ysbsq?file=/src/index.js
Все аргументы в пользу ущербного DI высосаны из пальца и не относятся к реальной жизни.

Самый абсурдный «аргумент» конечно:
Как только у некоторого модуля появляются селекторы и зависимость от глобального стора, модуль прибивается гвоздями к этому стору и получает в нем некое фиксированное место.

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

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

1) Уродство — это ваше представление о прекрасном. Нужно писать код максимально просто и понятно, и никак иначе.

2) runInAction конкретно тут не нужен, как и action. Вы же вообще не понимаете зачем они нужны и когда их нужно и использовать, однако пытаетесь вставить свои 5 копеек, более того вы говорите makeAutoObservable — уродливый синтаксис, в каком месте он уродливый то?) makeAutoObservable(this) в конструкторе класса, одна строчка, где тут уродство то?) Че за дичь вообще вы несете то?)

3) Кол-во кода в разы больше? Мда, а в в курсе что классы/функции и т.п. можно выносить в разные файлы и импортировать оттуда?) Вам привели наглядный пример где все специально в одном файле написано.
import { autorun, observable } from "mobx";

class WithFetch {
    @observable isFetching = false;
    @observable errorMessage = null;
    @observable.ref data = null;

    get = async (url: string) => {
        this.isFetching = true;
        try {
            const req = await fetch(url);
            const data = await req.json();
            this.data = data;

            return data;
        } catch (e) {
            console.error(e);
            this.errorMessage = e.message;
            throw new Error(e);
        } finally {
            this.isFetching = false;
        }
    };
}

class Posts {
    fetcher = new WithFetch();
    postId = null;

    fetchPosts = async (postId) => {
        this.postId = postId;
        await this.fetcher.get(`https://jsonplaceholder.typicode.com/posts/${postId}/comments`);
    };
}

const postsState = new Posts();

(async () => {
    await postsState.fetchPosts(1);
    await postsState.fetchPosts(22);
})();

autorun(() => {
    if (postsState.fetcher.isFetching) {
        console.log("Loading post...");
    } else {
        console.log(`Post ${postsState.postId} has ${postsState.fetcher.data.length} comments`);
    }
});


Ну вот, пожалуйста, не переключайте флаги, делов то, это ж элементарно:
class WithFetch {
    @observable isFetching = false;
    @observable errorMessage = null;
    @observable.ref data = null;

    get = async (url: string) => {
        this.isFetching = true;
        try {
            const req = await fetch(url);
            const data = await req.json();
            this.data = data;

            return data;
        } catch (e) {
            console.error(e);
            this.errorMessage = e.message;
            throw new Error(e);
        } finally {
            this.isFetching = false;
        }
    };
}

Один раз написал обертку для запросов к серверу и усё, получаешь удовольствие.
Можете раскрыть свою мысль про ущербность effector?

Далеко ходить не нужно даже за примерами из реального кода, открываете главную страницу эффектора и видите эту дичь:
import {createEvent, createStore, createEffect, sample} from 'effector'

const nextPost = createEvent()

const getCommentsFx = createEffect(async postId => {
  const url = `posts/${postId}/comments`
  const base = 'https://jsonplaceholder.typicode.com'
  const req = await fetch(`${base}/${url}`)
  return req.json()
})

const $postComments = createStore([])
  .on(getCommentsFx.doneData, (_, posts) => posts)

const $currentPost = createStore(1)
  .on(getCommentsFx.done, (_, {params: postId}) => postId)

const $status = combine(
  $currentPost, $postComments, getCommentsFx.pending,
  (postId, comments, isLoading) => isLoading
    ? 'Loading post...'
    : `Post ${postId} has ${comments.length} comments`
)

sample({
  source: $currentPost,
  clock: nextPost,
  fn: postId => postId + 1,
  target: getCommentsFx,
})

$status.watch(status => {
  console.log(status)
})

nextPost()


Вот повторение этого примера с использованием MobX'a:
import { autorun, observable } from "mobx";

class Posts {
    @observable isFetching = false;
    @observable.ref posts = [];
    postId = null;

    fetchPosts = async (postId) => {
        this.postId = postId;
        this.isFetching = true;
        const req = await fetch(`https://jsonplaceholder.typicode.com/posts/${postId}/comments`);
        this.posts = await req.json();
        this.isFetching = false;
    };
}

const postsState = new Posts();

(async () => {
    await postsState.fetchPosts(1);
    await postsState.fetchPosts(22);
})();

autorun(() => {
    if (postsState.isFetching) {
        console.log("Loading post...");
    } else {
        console.log(`Post ${postsState.postId} has ${postsState.posts.length} comments`);
    }
});


Очевидно что в effector'e лапша и надо напрягаться чтобы понять что там происходит, когда используешь MobX, то всё элементарно, просто смотришь сверху вниз, слева направо и все сразу понятно.

Effector использует топорный pub/sub, так ещё и в добавок ко всему иммутабильный, со всеми вытекающими проблемами и неудобствами, хотя JS уже более 10ти лет дает мощную штуку в виде getters/setters и последние 6 лет дает ещё более продвинутую штуку в виде Proxy.

Поэтому он и ущербный, раскрывает возможности языка на 0 из 10, добавляет удобство разработчику на 0 из 10.
тем временем в TS
NOTE  Decorators are an experimental feature that may change in future releases.

И что? Я их как в 2015 году писал, точно так же и пишу в 2021, 6 лет ими пользуюсь, одни плюсы, ни одного минуса. Обратная совместимость как минимум останется на долгие годы, так что минимум в ближайшие лет 10 можно вообще не думать по этому поводу.
Effector — очень крутой стейт-менеджер.

Вы в слове «крутой» сделали 8 ошибок, ведь правильно писать «ущербный».

К чему вы всё это написали то, мы же вроде в нашей эре живем? Тем более в 2021 году, MobX уже давным давно все это заменил.

Никаких спорных вещей вроде Proxy или декораторов.

Спорных???
1) Декораторы хотите используйте, хотите не используйте, это опционально.
2) Proxy уже 100 лет в обед существует в языке и шикарно себя показывает.

Где тут спорность то? Что-то ломается, что-то не работает?
Что такое, стрелочка не поворачивается? Когда кто-то использует менее эффективную технологию, то вы смеётесь над ним, а когда сами используете менее эффективную, так начинаются отмазки в пользу дибилов, не способных прочитать документацию и освоить куда более простую технологию.

Вы путаете.
Дело не только в эффективности, дело в совокупности всех факторов.
А касаемо $mol, вам же сто раз уже говорили, что по совокупности факторов он не пригоден для использования(из-за адского синтаксиса), и не важно насколько он эффективный и быстрый.

Если брать голую эффективность и производительность, то React это достаточно ущербная штука. Но если взять React + MobX, то по совокупности всех факторов и по сравнению со всеми остальными альтернативами, получается лучший вариант на сегодняшний день.
в совокупности c RxJS вообще будет отличное решение.

Для тех, кто любит когда кровь из глаз течёт глядя на такой код да, вообще отличное решение :D
А если ещё и придётся через недельку другую к этому коду вернуться и что-то там пофиксить или добавить фичу, вообще сказочное самовозгорание произойдет :D

Люблю тогда такой «код» пишут, сразу столько проектов на рынке появляется которые нужно переписать с чистого листа по человечески, сказка.
Меня умиляет, как вы смеётесь над теми, кто не пробовал мобх, но сами при этом не пробуете ничего лучше реакта. Парадокс Блаба во всей красе.

Кто сказал? Я пробовал всё из актуального, Vue (v2 и v3), Angular, Svelte, Flutter, React, Preact, Inferno и т.п. и лично для меня на сегодняшний день связка React + MobX является лучшей:
1) Cправляются со всеми моими проектами и задачами более чем достаточно.
2) Не связывают мне руки.
3) Дают легко читаемый, легко развиваемый и поддерживаемый код. Конечно если уметь его писать, если не уметь, то будет говно всегда)

Ваш любимый $mol не пробовал и не при каких обстоятельствах даже пробовать не буду, там настолько отвратительный синтаксис что мама не горюй. Путь он хоть будет работать в 100 раз быстрее реакта, будет в 1000 раз эффективней и т.п., всё равно из-за синтаксиса ни за что его не возьму.

Итого: для меня сейчас нету ничего лучше React'a + MobX.
Я рассуждаю о том, что видел в использовании в рамках крупных проектов и о том, чем пользовался сам.

Вы имеете ввиду древнее легаси, от которого воняет за километр. И не надо пытаться защищать такие проекты с точки зрения разработчика, это абсурдно. Топтаться годами на месте и тем более не смотреть по сторонам, не знаю какие есть инструменты, не пробуя их — тупиковый путь. Работая на таких проектах, вы автоматически отстаете от мира лет на 5. Про сильнейшую потерю навыков проектирования архитектуры и т.д. и т.п. я вообще молчу.
Про MobX мне действительно мало известно

Ахахах, жесть, в 2021 году слышать такие слова нелепо.
Очень странно, откуда вы тогда вообще про React слышали? Это же технология из нашей эры. К сожалению не удивительно тогда почему вы думаете что redux-toolkit это «норм».
но радикализм в выборе технологий осуждаю.

Сменить Redux на MobX это типо радикальный шаг который нафиг надо делать да?) Пересесть с гужевых повозок на машины тоже радикализм да?) Про освоение авиации и перемещение по воздуху я вообще тогда молчу) С такой логикой вы поступаете радикально, когда пишете на JS, ведь есть же замечательный assembler.
Вы серьезно не знаете что такое MobX? В чем смыл рассуждать об откровенно слабых и ущербных полумерах в виде redux-toolkit, когда уже давно существует по настоящему правильное и хорошее решение?

Information

Rating
Does not participate
Registered
Activity