The components used here seem like theyre very specific to the needs of the application that was built. I have no idea how this type of framework would be used to build anything else.
To be more specific, he has the "Source" and "Detail" elements, but theres no apparent way of what piece of data is being synced across them or how theyre connected. Therefore, if I wanted to change any of that, I'd be completely lost. Did anyone else understand how the data actually flows across these pieces?
I hate to be that guy but what the guy is doing is adding "complexity"; he did not create zero-cost patterns or abstractions that reduce 10 lines of code to 1 while allowing for fine-grained customization of any step.
As someone who builds apps for a living, the 90% of the time is spent on the "last minute" customization and fighting the stack. This is why I pick widely used stacks. They might not be better but I have higher chances of finding someone else who had a similar issue.
Also I'd never use something that hides what is pushing/pulling from the server let alone configure the database structure for me. That would be really fun as I already spend 1/2 my time debugging what went wrong and finding it. Working with a black box is not going to help in any of that.
There is a reason why people steer to React/Redux. The world is not a Todo list app, and most of the time you need some creative work and you need something agnostic that can be programmed. Coupled with GraphQl, you can have a nice separation between your front and back ends and test them appropriately.
> the 90% of the time is spent on the "last minute" customization and fighting the stack. This is why I pick widely used stacks
I am currently on a project where the initial specs worked with Adobe Captivate. Then the spec exploded and we are making tortured attempts to make it still work with Captivate.
Exactly. Just wait until you have to auth with a 3rd party API, fetch the request async, do a transformation on the response, load it into a 3rd party UI grid, add custom styling to the grid, and then add sorting and filtering on top. And this isn't anything particularly exotic--it's a wash-rinse-'n'-repeat you find over and over in products--and it'd be a royal PITA to build it in a framework that's basically a thin layer on top of HTML.
> Did anyone else understand how the data actually flows across these pieces?
I'm guessing it goes into a database somewhere. But I'm not sure how, what the database's schema is, or how easy it would be to interact with it from an external program.
they are linked through the "target" attribute which has a default value. since there is only one source and one destination in the demo, it can be omitted entirely. (5:03 in the video)
To be more specific, he has the "Source" and "Detail" elements, but theres no apparent way of what piece of data is being synced across them or how theyre connected. Therefore, if I wanted to change any of that, I'd be completely lost. Did anyone else understand how the data actually flows across these pieces?