Comments 20
В треде пол микро API, люди пишут, что фильтры и DI — это слишком сложно и надо позволить писать без всего этого.
Как-то это все странно.
Мое первое впечателние весьма не плохое, лучше, чем от ангулярки. Уже начали появляться вакансии на рынке с этой технологией. Может займет какую либо нишу среди фуллстеков.
Т.е. остается только сервер. Но даже тот сайт, который они сделали (themesof.net) заметно лагает на открытии узлов дерева. Каждый клик мыши идет на сервер по веб-сокетам и получает UI дельту.
Я понимаю, что в некоторых случаях это даже неплохо, но для современного веба, такая заторможенная реакция UI — не айс.
Плюс, Microsoft такой Microsoft. Когда написание компонентов на Blazor можно было сделать реально легковесным, типо
@component MyComponent
@{
public string Name, LastName;
}
<div>
{Name}<br>{LastName}
</div>
Они пошли по дороге — опишите все поля как свойства, навешайте на них специальных атрибутов, ведь так не понятно, что публичные свойства они на то и публичные, что они отовсюду видны, а вот мы в Blazor Team не понимаем.
Короче, как обычно. Можно было сделать зашибенный React для C#, а получился восьминогий семихрен…
Т.е. остается только сервер.
Без рест апи все равно не обойтись, а интерфейс уже строить на блейзоре, т.е. все таки юзать «все на клиенте»? Мне лично очень нравится вся «мошь» шарпа.
навешайте на них специальных атрибутов, ведь так не понятно
import { Input} from '@angular/core';
...
@Input() publicProperty : string;
или
export default {
name: "Item",
props: {
city: {}
}
}
Идеального фреймфорка для фронта еще не придумали ):
export const MyComponent = ({name, lastName}) =>
<div>{name}<br>{lastName}</div>
Свойства передаются от родительских компонентов к дочерним. Компоненты получают свойства как множество неизменяемых (англ. immutable) значений, поэтому компонент не может напрямую изменять свойства, но может вызывать изменения через callback-функции. Такой механизм называют «свойства вниз, события наверх».
Это сложно назвать идеальным фреймфорком для фронта (как по мне)
React и правда тяжело назвать идеальным фреймворком, но вот процитированная вами часть — это единственный адекватный способ работы со свойствами ( с поправкой на то, что неизменяемость значений понимается как мелкая, а не глубокая).
Правильная структура этого элемента — залог здорового ререндеринга.
Они пошли по дороге — опишите все поля как свойства, навешайте на них специальных атрибутов, ведь так не понятно, что публичные свойства они на то и публичные, что они отовсюду видны, а вот мы в Blazor Team не понимаем.
У каждого своя идеальность, но по мне проще прилепить аттрибут на свойство, чем городить по-сути ридонли переменные в контрукторах и колбэки. Имхо, MVVM, при правильной реализации, лучшее, что есть для UI.
MVVM — это лучшее, что придумал Microsoft, но не лучшее из того, что вообще придумали.
За 10 лет MVVM, я склоняюсь к мнению, что callback-и и простые immutable объекты вкупе с Flux принципами — самое простое и эффективное решение. Минимум концепций, максимум возможностей для суперэффективного рендеринга и высокой производительности.
Плюс к этому, никто не мешает компонентам быть платформозависимыми, легкотестируемыми, ведь им нужны только свойства. Никаких тебе моделей, интерфейсов.
Eventbus решает остальные проблемы, если они возникают. Плюс есть концепция контекстов, что многие задачи упрощает ещё больше.
Microsoft опять изобрел велосипед, причем не самый лучший. А были все шансы
Не забывайте одного, мир на MS не заканчивается. Будьте открыты к новому, думайте своей головой, не бойтесь пробовать.
В MS работают обыкновенные люди, не лучше и не хуже вас. Когда они делают что-то хорошо, это заслуживает похвалы. Когда они косячат, нужно сразу им говорить, иначе поезд уедет совсем не туда, и всем будет только хуже.
Не забывайте одного, мир на MS не заканчивается. Будьте открыты к новому, думайте своей головой, не бойтесь пробовать.
Можете применить Ваш же совет и открыться для Blazor. Успешно используем Blazor уже сейчас и экономим время на разработке SPA приложений. Скорость получается выше чем на React, код легче читать и понимать для новичков. Это не панацея и не всегда он будет подходить, но в целом продукт отличный, а если осуществлят планы, которые освещали, то будет очень-очень круто. Нужен конкурент Javascript'у.
Мне вот что интересно. Сколько у вас маркапа в коде компонентов? А сколько кода в маркапе? Может быть удобнее расширить C# и добавить в него маркап конструкции, как в VB когда-то? Сделать что-то типо методов расширений, чтобы маркап превратился в их вызовы? Что бы можно было подключить другой namespace и вуаля — другая реализация DOM/XML/HTML?
Кто-то скажет, UI патчи идут в бинарном формате, это быстро, модно, молодежно. Но в случае Реакта вам тоже ведь никто не навязывает JSON по RESTу гонять, можно и по-взрослому — бинарные данные по сокетам. BSON и другие форматы вам в помощь, библиотек уже хватает. Компрессию тоже можно на сервере включить, посмотреть.
Обновления ASP.NET Core в .NET 6 Preview 1