Eu vi em alguma issue da dart-lang que uma das razões para eles fazerem dessa forma era pra evitar as breaking changes entre o Dart2 e o Dart3, mas na minha opinião a forma definida soa mais como um regresso do que qualquer outra coisa… Esse tipo de coisa faz eu pensar que de fato seria melhor a Google ter adotado o Kotlin para o Flutter kkkkkkk. Vlw pelo vídeo, professor!!
É um ponto de vista a se olhar, no meu ponto deu mais liberdade para construir códigos mais específicos e mais restrições em libs para que o desenvolvimento orientado a packages surjam, pra mim isso é uma grande vantagem mas poucos realmente sabem o poder disso.
Sim, a especificação traz muita informação que foi usada nas decisões de API… era melhor uma API mais similar a outras linguagens, mas não duvido que a comunidade logo comece a abrir issues de discussão como a sintaxe do switch
Alguns especialistas em Flutter ficaram chocados quando foram testar de forma "ingênua" (sem ler a documentação) - apenas não se comporta como uma interface tradicional :\
Obrigado pelo conteúdo, como sempre de excelência. Mas esses modificadores me deixaram muito confuso, eu trabalho no dia a dia com C# e não consegui imaginar esses modificadores em um numa aplicação real.
A motivação da interface era a que deveria ser: evitar que uma interface fosse herdada e que pudesse apenas ser implementada. Isso de fato se concretizou (mas no acesso e na implementação externa). O mais esquisito na minha opinião foi a possibilidade de construção. A motivação dos modificadores, de modo geral, foi manter "essa flexibilidade" que existe no Dart internamente, possibilitando novos recursos para criar limitações quando necessário (para uso externo). A spec ta disponível em github.com/dart-lang/language/blob/main/accepted/future-releases/class-modifiers/feature-specification.md (é bem longa)...
@@drantunes perfeito professo, não fui claro na minha dúvida. Mas seria extamente essa mesma, sobre conseguir construir direto em uma interface. Não me recordo de outras tecnologias que utilizei poder "implementar ao mesmo tempo que desenho o contrato" 😅 Mas obrigadão pelo conteúdo e atenção!!!
queria que o dart adotasse aquele esquema do java de vc saber quais exceptions o método pode emitir, dai fica a cargo do dev dar catch ou jogar pra frente
Professor me surgiu uma dúvida... Tentei fazer um teste unitário e precisei mocar uma classe sealed, pra IDE não ficar mostrando aviso precisei colocar a anotação // ignore: subtype_of_sealed_class na minha classe mock... É dessa forma mesmo ou estou fazendo alguma coisa de errado? ou eu nem deveria mocar uma classe sealed? Obs.: estava tentando fazer um mock do DocumentReference do firebase
Sim, esse é um dos problemas que comentei no vídeo. Uma classe selada não pode ser construída, estendida ou implementada, apenas na mesma biblioteca. No teste eu usaria o resultado da "adaptação" do DocumentReference e não a referência propriamente direta. Outra ideia é criar um adapter do documentreference na sua camada de armazenamento e usar ela nos testes ... afinal, o firestore já está testado... Qualquer coisa, deixa mais info aqui...
@@drantunes seria uma boa opção, a intenção era mocar os resultados do DocumentReference pra tomar as decisões já dentro do contexto da aplicação... Acredito que se criasse um adapter e fosse fazer os testes unitários nele teria o msm problema kkkk... De qualquer forma utilizando a anotação que eu falei no comentário acima, o editor para de reclamar e o mock funciona... como está sendo utilizado somente para testes estou deixando dessa forma msm
Não, são coisas diferentes. O equatable (tem vídeo aqui no canal) serve para a comparação de objetos, com a redefinição da propriedade == para uma checagem mais granular. Já o final serve para informar que a classe é final, ou seja, não pode ser implementada ou estendida por outras classes.
Caraca, esses modificadores ficaram muito confusos. Se a gente der uma olhada em como o Kotlin trabalha com isso, podemos ver o quanto a linguagem está a anos luz do Dart. Gosto muito de Flutter, mas não sei, essa nova versão do dart tá bem difícil de engolir kkk. Parabéns pelo conteúdo Professor!! 👏🏽👏🏽
Parabéns pela aula. Que horrível o que fizeram, trocar o comportamento esperando destes modificadores.. só complica e alimenta a curva de aprendizado de quem vem de outras linguagens.. Sem fala que sinto falta na linguagem, os modificadores de propriedade!!
Acho que o Google quis mostrar inovação, fazer "moda" digamos assim, ser diferenciado, e não ser igual aos outros. Acho que eles quís renovar, não precisaca desse arrodeio todo, sei que flutter é para vários segmentos. Mobile, desktop, web. Mas ainda sim, acho que deveria só feito como outras linguagens.
Diego, excelente estratégia! E concordo contigo sobre a perda de conformidade da interface com o que já temos em diferentes linguagens. E falando sobre complexidades, você julga que o State Pattern junto ao Mobx agrega facilidade? Ou é desnecessário? Se positivo, pode compartilhar um snippet de código da implementação? Algo assim?: @drantunes import 'package:flutter_modular/flutter_modular.dart'; import 'package:mobx/mobx.dart'; import 'package:nexar_flow_gen2/src/modules/splash/data/services/users_sector_service_dio2.dart'; import 'package:nexar_flow_gen2/src/modules/splash/data/stores/users_state.dart'; import 'package:nexar_flow_gen2/src/modules/splash/interactors/consumers/users_in_sector_consumer2.dart'; import 'package:nexar_flow_gen2/src/modules/splash/interactors/models/user_model.dart'; part 'users_store.g.dart'; class UsersStore = _UsersStoreBase with _$UsersStore; abstract class _UsersStoreBase with Store { @observable UsersState usersState = UsersInitial(); //Historical @observable int value = 100; @action void increment() { value++; } @observable String currentSector = '861517292097896449'; @action void setCurrentSector(String newSector) { currentSector = newSector; } @observable ObservableList users = ObservableList(); @action Future getUsers(sector) async { usersState = UsersLoading(); final UsersInSectorConsumer2 consumer = UsersInSectorConsumer2(); try { // Renomeie o parâmetro final payload = { 'payload': {'sector': sector, 'role': 'medico'} }; var newUsers = await consumer.consume(UsersFromSectorDio2(), payload); print("THE NEW USERS ARE: $newUsers"); // Atribua o valor ao usuário observável users.addAll(newUsers); usersState = UsersLoaded(users); } catch (e) { usersState = UsersError(e.toString()); } } }
Funciona sim! Eu particularmente tenho adotado soluções mais simples como um wrapper sob o ValueNotifier mesmo e tem cumprido bem a função. Em breve devo trazer mais sobre isso no canal
Melhor canal de flutter do UA-cam!
Diego, excelente material!
Muito obrigado pelo seu apoio Leonardo!! Grande abraço e desejo todo o sucesso pra você! 🙏
Caramba, esta implementação de "interface" conseguiu deixar o Dart muito confuso
Show demais sua aula!!!!!
Show, ótima aula! O exemplo com o Bloc esclareceu muito sobre o uso desses modificadores
Obrigado pela aula professor, mas um conteúdo show.
Bem interessante, parabéns pela explicação, faça mais vídeos a respeito. Abraços de Formosa-Go
Ótimo vídeo Diego, valeu!
Disponha!
Eu vi em alguma issue da dart-lang que uma das razões para eles fazerem dessa forma era pra evitar as breaking changes entre o Dart2 e o Dart3, mas na minha opinião a forma definida soa mais como um regresso do que qualquer outra coisa…
Esse tipo de coisa faz eu pensar que de fato seria melhor a Google ter adotado o Kotlin para o Flutter kkkkkkk. Vlw pelo vídeo, professor!!
É um ponto de vista a se olhar, no meu ponto deu mais liberdade para construir códigos mais específicos e mais restrições em libs para que o desenvolvimento orientado a packages surjam, pra mim isso é uma grande vantagem mas poucos realmente sabem o poder disso.
Sim, a especificação traz muita informação que foi usada nas decisões de API… era melhor uma API mais similar a outras linguagens, mas não duvido que a comunidade logo comece a abrir issues de discussão como a sintaxe do switch
@@drantunes Com certeza tem muito a melhorar.
@@mthsenaoq seria oriantado a packages ?
@@dossantos3800 Um package por módulo, tipo o que um multirepo faz.
Parabéns pelo conteúdo professor.
Thank you for the wonderful video sir it is very helpful for me and my team, Thanks again sir
Top demais!
Valeu bro 👊
Vídeo de qualidade, parabéns pelo conteúdo!!!
Muito bom professor 😮!!
Ótimo vídeo, como sempre! Parabéns pelo conteúdo
Vlw pelo conteúdo, estava esperando alguém falar sobre os novos modificadores. Pq essa modificar de "interface" ficou bem confuso. Kkkkkk
Alguns especialistas em Flutter ficaram chocados quando foram testar de forma "ingênua" (sem ler a documentação) - apenas não se comporta como uma interface tradicional :\
Eu nao achei, linguagens como C# tem ambos, tanto quanto interface, quanto astract..
@@dossantos3800 por isso, mas em java não tem acho que isso que para alguns ficou confuso, pois dependo da linguagem que vc fica da confusão.
Sensacional
Obrigado pelo conteúdo, como sempre de excelência.
Mas esses modificadores me deixaram muito confuso, eu trabalho no dia a dia com C# e não consegui imaginar esses modificadores em um numa aplicação real.
Tem alguns que são apenas para uso em bibliotecas mesmo. Mas na prática você verá ou não a necessidade
Ótima explicação, professor. Poderia disponibilizar o código?
Assim que der envio pro git, mas pelo vídeo consegue testar sem problemas ;)
Cara essa interface virou um Frankstein, apenas a implementação de Sealed que me agradou
Sim, não ficou intuitivo. Mas para acesso externo e para criar limitações na API de classes ficou bom (mas não ideal) :\
Sabe nos dizer o porque, os fundamentos oude onde que eles utilizaram para deixar o uso do "interface" dessa maneira?
A motivação da interface era a que deveria ser: evitar que uma interface fosse herdada e que pudesse apenas ser implementada. Isso de fato se concretizou (mas no acesso e na implementação externa). O mais esquisito na minha opinião foi a possibilidade de construção.
A motivação dos modificadores, de modo geral, foi manter "essa flexibilidade" que existe no Dart internamente, possibilitando novos recursos para criar limitações quando necessário (para uso externo).
A spec ta disponível em github.com/dart-lang/language/blob/main/accepted/future-releases/class-modifiers/feature-specification.md (é bem longa)...
@@drantunes perfeito professo, não fui claro na minha dúvida. Mas seria extamente essa mesma, sobre conseguir construir direto em uma interface.
Não me recordo de outras tecnologias que utilizei poder "implementar ao mesmo tempo que desenho o contrato" 😅
Mas obrigadão pelo conteúdo e atenção!!!
queria que o dart adotasse aquele esquema do java de vc saber quais exceptions o método pode emitir, dai fica a cargo do dev dar catch ou jogar pra frente
Professor me surgiu uma dúvida... Tentei fazer um teste unitário e precisei mocar uma classe sealed, pra IDE não ficar mostrando aviso precisei colocar a anotação // ignore: subtype_of_sealed_class na minha classe mock... É dessa forma mesmo ou estou fazendo alguma coisa de errado? ou eu nem deveria mocar uma classe sealed? Obs.: estava tentando fazer um mock do DocumentReference do firebase
Sim, esse é um dos problemas que comentei no vídeo. Uma classe selada não pode ser construída, estendida ou implementada, apenas na mesma biblioteca. No teste eu usaria o resultado da "adaptação" do DocumentReference e não a referência propriamente direta. Outra ideia é criar um adapter do documentreference na sua camada de armazenamento e usar ela nos testes ... afinal, o firestore já está testado... Qualquer coisa, deixa mais info aqui...
@@drantunes seria uma boa opção, a intenção era mocar os resultados do DocumentReference pra tomar as decisões já dentro do contexto da aplicação... Acredito que se criasse um adapter e fosse fazer os testes unitários nele teria o msm problema kkkk... De qualquer forma utilizando a anotação que eu falei no comentário acima, o editor para de reclamar e o mock funciona... como está sendo utilizado somente para testes estou deixando dessa forma msm
Usar final class seria o mesmo que usar o Equatable?
Não, são coisas diferentes. O equatable (tem vídeo aqui no canal) serve para a comparação de objetos, com a redefinição da propriedade == para uma checagem mais granular. Já o final serve para informar que a classe é final, ou seja, não pode ser implementada ou estendida por outras classes.
bom demaisss só não curti mt a interface poder ser construida eu so mudaria isso
Sim, concordo
Caraca, esses modificadores ficaram muito confusos. Se a gente der uma olhada em como o Kotlin trabalha com isso, podemos ver o quanto a linguagem está a anos luz do Dart. Gosto muito de Flutter, mas não sei, essa nova versão do dart tá bem difícil de engolir kkk. Parabéns pelo conteúdo Professor!! 👏🏽👏🏽
Sim, bem confuso em nível de biblioteca… mas acesso externo até ficou razoável
Não gostei, achei uma mudança muito radical, pra que fazer isso? Tão entupindo a linguagem de coisa desnecessária
Parabéns pela aula. Que horrível o que fizeram, trocar o comportamento esperando destes modificadores.. só complica e alimenta a curva de aprendizado de quem vem de outras linguagens..
Sem fala que sinto falta na linguagem, os modificadores de propriedade!!
Acho que o Google quis mostrar inovação, fazer "moda" digamos assim, ser diferenciado, e não ser igual aos outros. Acho que eles quís renovar, não precisaca desse arrodeio todo, sei que flutter é para vários segmentos. Mobile, desktop, web. Mas ainda sim, acho que deveria só feito como outras linguagens.
Pra que facilitar se vc pode complicar kkkkk
🤣 é a nossa vida em programação
@@drantunes 🤷🏻♂️ kkkkkkk
Diego, excelente estratégia! E concordo contigo sobre a perda de conformidade da interface com o que já temos em diferentes linguagens. E falando sobre complexidades, você julga que o State Pattern junto ao Mobx agrega facilidade? Ou é desnecessário? Se positivo, pode compartilhar um snippet de código da implementação?
Algo assim?: @drantunes
import 'package:flutter_modular/flutter_modular.dart';
import 'package:mobx/mobx.dart';
import 'package:nexar_flow_gen2/src/modules/splash/data/services/users_sector_service_dio2.dart';
import 'package:nexar_flow_gen2/src/modules/splash/data/stores/users_state.dart';
import 'package:nexar_flow_gen2/src/modules/splash/interactors/consumers/users_in_sector_consumer2.dart';
import 'package:nexar_flow_gen2/src/modules/splash/interactors/models/user_model.dart';
part 'users_store.g.dart';
class UsersStore = _UsersStoreBase with _$UsersStore;
abstract class _UsersStoreBase with Store {
@observable
UsersState usersState = UsersInitial();
//Historical
@observable
int value = 100;
@action
void increment() {
value++;
}
@observable
String currentSector = '861517292097896449';
@action
void setCurrentSector(String newSector) {
currentSector = newSector;
}
@observable
ObservableList users = ObservableList();
@action
Future getUsers(sector) async {
usersState = UsersLoading();
final UsersInSectorConsumer2 consumer = UsersInSectorConsumer2();
try {
// Renomeie o parâmetro
final payload = {
'payload': {'sector': sector, 'role': 'medico'}
};
var newUsers = await consumer.consume(UsersFromSectorDio2(), payload);
print("THE NEW USERS ARE: $newUsers");
// Atribua o valor ao usuário observável
users.addAll(newUsers);
usersState = UsersLoaded(users);
} catch (e) {
usersState = UsersError(e.toString());
}
}
}
Funciona sim! Eu particularmente tenho adotado soluções mais simples como um wrapper sob o ValueNotifier mesmo e tem cumprido bem a função. Em breve devo trazer mais sobre isso no canal