Front-End Architecture 101 - Nir Kaufman @ ReactNYC

In this session, we will discuss front-end architecture, define what it is and how to leverage solid design principles to our system. Along the way, we will learn how React fits in with this puzzle and why frameworks are not a replacement to clean architecture.
Source code
github.com/demo-projects/reac...

[@Gazunklenut]

Nice talk keep it up Nir!

[@lakmaljayawardana5898]

Wow.. simply enlightening :)

[@sameeravhad6266]

Very nice explained. Low Coupling and High cohesion. Thanks.

[@chenrvn]

Thanks for a Gr8 talk
I love the way u describe the soc
Some feedbacks:
- u say that entity doesn't need to depend anything but your book antity depend on stuff. (see the import, it depend on typeORM stuff which mean that u cannot just take it to another app, so it's not pure I dependency)
- related to the use case, bussniss logic part, again it's depend on mobax where u just need to depend on entities
What do u think?
Thanks

[@amguruprasath8037]

Beautiful.

[@nuwanthuduwage6869]

Impressive!!!!!!!

[@AndiSyafrianda]

Thank you 🙏🏻

[@oemeraran8183]

Why would you use typescript if u write "@ts-ignore" in every tsx file?

[@johanneszilg6901]

Because MobX prefers to use decorators and those are only available in TypeScript.

[@DmitriySidorenko]

Good theory part but poor demo which contradicts the theory in some cases like direct dependency on implementation details (MobX and TypeOrm)

[@jozeGmail]

great talk :) the only thing I don t agree is about vscode. I have used many ides and that one suits me best and it s free :D I can buy icecream with the saved money

[@ReactNYC]

Start using Webstorm and you could afford beer.

[@sergeys6034]

IDE will save you a lot of time worthing buying a license. GIT client, conflict resloving, refactor tools, plugins, real powerful autocomplete, highlights are on different level in webstorm. I cannot imaging being that productive using code editors

[@mikezcooler]

Good theory, and nice to introduce Type ORM which looks to be a good orm for node js. However from an architectural perspective, the code implementation ends up implementing our Domain, Application, and Infrastructure all of which should be entirely separate inside of what should simply just be the Presentation Layer. So it has mashed up all the other layers of a Clean Architecture inside the Presentation, and it is no longer a clean architecture.

[@cristianscript5649]

do you have a good example about clean architecture

[@AnopSinghRanawatperl]

Thanks😜

[@iAmCoded]

Ayy the advanced redux patterns guy

[@romanilyushin4827]

Nope, it's his horse-brother-twin.

[@nirkaufman101]

My evil horse-brother-twin

[@iAmCoded]

lmao

[@dimka11ggg]

Why ORM on frontend?

[@handsome_man69]

Handsome man

[@swssdev9163]

And you just had to bash vscode. so low.
nice talk btw.

[@nikosc]

The concepts in this talk are great, but they are too many and too high level for a developer without a strong backend experience to grasp. I also prefer webstorm.

[@jww0007]

you don't need backend experience

[@aammssaamm]

Useless hardcoded HTML.

[@cagmz]

Very little substance in this talk. Not recommended.

[@szeredaiakos]

The cohesive elements or categories of your application are the BookForm and the BookList, NOT "entities", "infrastructure" or "components".
You are building a BOOK STORE and not NOT entities, infrastructure and components.
If you talk about architecture, F*IN APPLY IT!

[@aammssaamm]

15:05 bad advice - any app should be built from GUI and not other way around. Data structure should be defined by GUI and not buy some lazy backend dude.

[@DmitriySidorenko]

Anne Smith then what will you do when GUI changes?

[@aammssaamm]

@@DmitriySidorenko Use your brain, babe.

[@m12652]

Data structure should be dictated by the data and the way it is to be used and manipulated....

[@aammssaamm]

@@m12652 Wrong approach. The better your data the less work you do on front. Unless you are a slave who binds all data manually.

[@m12652]

Anne Smith I think we’ve crossed. Get the data structure right and you can do what you like with the interface, it will always be natural. Get it wrong and you can still do a great interface but the amount of overhead goes through the roof. A good interface does necessarily lead to a good data structure, though designing one before you start often helps. A bad data structure only gets worse. Couldn’t watch all this video btw, bailed after 5 as he wasn’t saying anything new.