Ember.js Berlin / 4x Presentation Special / July 2021

[Music] [Music] so [Music] foreign [Music] [Music] foreign [Music] [Applause] [Music] then [Music] so [Music] yeah then hi and welcome everyone to the uh july edition of the amber berlin meetup really glad to see so many of you folks here from all different time zones at our event today and yeah just like really very cool to get you all together today so um yeah i hope you also can learn and enjoy a lot from being here uh also before we uh actually get into our short intro about like the meetup just like a couple of like shout outs and to our sponsors and also supporters of this meetup first of all there's pusher who has been a long time supporter of our meet up by providing us like the support with video content creation recording and also distribution of the video content alex royce you also already have seen here the call is doing this for us like for many years we're very grateful for this so thank you so much and also a big shout out to harvest who um has also been a long time supporter in our meet up and has been yeah supporting us throughout all these years uh very grateful for this as well so thank you so much also who is actually like our organizer team it's consisting of joshua clements and me you can also yeah if you want to comment on anything or just chat with us like find us on twitter and and we are also always very grateful for uh feedback or kind of like ideas that you have for me that as well also just like a few words about like what this meetup is because like some of you might not have been here before uh because this is like one of our few virtual events so far or as some of you haven't been here like in a while and it's first of all and every now and then meet up so if some of you are wondering what's like the kind of like rhythm of it we kind of like do it whenever we have like the time for it and usually this consists of uh talk nights like this one also like me to greets uh usually like in berlin and also online events since recently since like the um yeah kind of like more being at home situation started and uh also like very important for us is that our meetup also tries to aim and support an inclusive worker environment uh we lend a lot of like this ideas from the community guidelines from amber which you can also find on mhs.com guidelines but the too long didn't read is mostly uh that we expect everyone here at the event to be like a kind and supportive person that everyone is just like being mindful of like being a kind person like to others and this includes like other audience members but also of course like our amazing speakers like today and i'm not sure how many of you have already like spoken that event but nothing's like so much nicer than actually presenting something in front of people and also getting like a lot of like nice and kind feedback afterwards so we really encourage everyone to keep this in mind and and then like the main point of our introduction at every meetup is um our main pitch which consists of asking you if you have like any ideas for talks that you want to give for the meetup anything that you want to present that you worked on anything that you learned recently about ember that's super interesting if you have like any ideas like even if you think like oh i'm actually not entirely sure if this would fit i would love to hear about it and feel free to reach out to us on any of our channels which is mostly amber linus on twitter you can follow us there and also like tweet at us if you have like some talk ideas on general just want to let us know about something interesting you can also reach out to us on the meetup.com page um and there you can also just like um kind of like chat to us like it's organizers we also have an email address we kind of check it very regularly so maybe try twitter first but also kind of like eventually get back to you if you send us an email and last but not least you can also find most of us on the discord and any questions on this so far on the intro everyone happy cool and with this set we can already get into our agenda for tonight and we have like four amazing talks by um yeah a lot of like interesting emma developers in our community talking about like the work and first of all we will hear a very interesting talk by ben demboski about embroider and how he actually worked on using embroider to leverage route splitting in a very exciting emma project very interested to hear about this and also we will have a like a talk by agar padilla about their color blindness emulator blue with ember and accessibility project and right afterwards after this we have short break and right after the break we will have two other amazing talks and with this set i would like to encourage all of you to meet yourself and give like a nice uh clap up for ben for his talk about embroider from zero to us between 3.5 weeks thanks jessica and uh i'm impressed that you pronounced my last name right for some reason people always want to pronounce it dembowski so it's gotten to the point that i don't even bother correcting people anymore but uh but you nailed it so um let me bring up my slides here okay everyone seeing that so uh as as you can see uh just from this headliner slide so embroider from zero to route splitting in 3.5 weeks so uh a couple months ago now um i went through an effort of porting our app over to uh to embroider took about three and a half weeks uh to do the full thing and uh i wrote up an article on it afterwards and most of this talk is kind of adapted from that article so i'm gonna move relatively quickly through the kind of slides and the meat of the information um to leave time for uh for questions because you know i could could have just brought up my article and read it to you all but that doesn't seem like the most interesting use of time here so um oh i i skipped my greeting i was going to say greetings from just becoming sunny seattle uh it's it's not terribly apocalyptically hot out here anymore like it was a couple weeks ago although it looks like our smoky season might be coming early and so it might get terribly apocalyptically smoky in a couple weeks but right now it's beautiful and lovely and and we're all enjoying it while it lasts so back to the talk uh so uh who am i i'm ben demboski i'm the cto at rowan patents which is a company that does several different things but the the software portion of it focuses on building software for patent attorneys to uh to help automate their workflows and and whatnot um i've used ember for about seven years uh both professionally and for kind of side projects and i've learned everything i know about embroider uh in the process of porting our app to it i knew just a tiny bit about it and some theoretical benefits we'd get from it before i dove into it i'm currently suffering from some amount of imposter syndrome because i'm by no means an embroider expert yet here i am uh you know giving a talk about it i'm more some guy that stumbled his way through the porting and learned a lot in the process but you know i guess that's enough to uh to share to help you all stumble your way through someday or uh you know maybe by then the uh it'll things will be moved along but they'll be you know more more guides and whatnot and less stumbling um and you can find me on twitter and discord either uh in either place at bendemboski um so uh the app that we ported to uh to embroider so it's a multi-window ember electron desktop app and kind of think of think of it kind of like an ide that's how we think of it as an ide for patent attorneys except for reasons it it makes sense for their productivity to have things in multiple windows rather than just multiple panes within the same window um so uh so the the attorney will have multiple windows open with different tool sets in them at the same time they can cross-reference and they're syncing data in between them so a lot of the routes a lot of our ember routes are only ever rendered in one window so loading the entire app in every window would be needlessly memory consumptive i might have just made up that word consumptive needlessly consuming memory and also more than just our ember code we have a lot of third-party libraries that are only used by code in in one window things to do natural language processing type analysis and that sort of thing so for us memory footprint uh that's including code size is a big concern because multiple windows multiplies the any any code that's loaded and all the windows you know gets multiplied by however many windows are open and it it can be a number of windows and then i'd spit out some stats on our app just so if you're trying to i don't know compare yours to ours in terms of sizing maybe the effort or something so so our goal in the porting was to uh was to control the the code driven memory footprint with minimal engineering effort uh and to do that via uh tree shaking and and route splitting and when i say tree shaking uh i i i i realized after i wrote up these slides that that it's it's more than just tree shaking but basically let's just say modern javascript bundling techniques for for reducing the size of the bundle and tree shaking is a notable one of those but there's uh there's others as well we had previously using ember auto import and a whole bunch of manual webpack configuration to explicitly strip out code that we didn't need in certain windows and stuff had achieved a pretty good amount of memory footprint managed code driven memory footprint management but the minimal engineering effort part was was not there so we were looking for kind of a set it and forget it type solution with minimal ongoing maintenance um so uh so before getting into some of the slightly nittier grittier uh the my overall impressions of embroider are more or less the same as they were when i when i uh wrote the article that i would kind of classify it as late stage alpha or early stage beta quality software so the core functionality is solid fairly severe bugs aren't that uncommon still the documentation is somewhat minimal and so porting a complex app to embroider can be pretty effort intensive and keeping it up to date across new releases of embroider can also be somewhat effort intensive as it's still in a state where regressions you know come up and can can require some effort to figure out how to work around them um or configure around them um but i did find that production stability is very high none of those things that keep me up at night of of i build it once in ci and then i rebuild with exactly the same code and the production bundle is different you know none of that stuff happens what i've found is that once you know once it's building and and i've got it all lined up it's it's very stable it's just uh it's just as embroider changes and and uh and and evolves that introduces some instability updating to those newer versions uh the dev environment stability i've i've found to be pretty high uh it's pretty stable there's some minor hiccups nothing that i've found to be a major major issue and i think a lot of that is has to do with with kind of source map flakiness which often just refreshing the window a couple times addresses so i'm not sure if that's really embroider's fault or webpack's fault or or chrome devtools is fault but uh so those are my high-level impressions um so a kind of really oversimplified overview of of what embroider does is it uh is it takes your your ember app and and assembles it and all of the add-ons into a kind of a vanilla node.js project that's that's kind of hidden or already resolved all the unique behaviors of ember and ember cli so it's it's run the broccoli pipeline and gotten all the add-ons to contribute their assets but then it assembles it into a kind of static node.js project with the package.json and node modules put in the right place and and whatnot so that then it can point uh a standard uh packager like web webpack is the current one that's supported although that's uh working on support for for some others but uh in theory you should be able to use anything webpack or rollup or anything like that but yeah i can point webpack at it and then with some custom loaders and whatnot then webpack turns it into a browser bundle so one of the big goals is to leverage everything that's been done out in the community on on bundlers rather than ember having to maintain our own bundler that kind of duplicates a bunch of functionality that the broader community is working on and then the last step is it injects the the the bundled scripts and other webpack generated resources back into your index.html using some of those special rules that uh that that we have an ember where like the root url gets filled in if you're hosting on a cdn and that sort of stuff so that's kind of an overview of what embroider does and my reason for is is to provide some context for some of the hard parts that i found according to embroider so one of them was the package.json dependencies when embroiders assembling the vanilla node.js version of the application it relies heavily on information in the apps and add-ons package.jsons to set things up properly to know which packages to include and the kind of assembled you know vanilla js package so that webpack will do the right thing and so missing dependencies but but under ember cli it was fine because the package was still in node modules because it was a transitive dependency of some add-on but your app didn't call it out as a dependency even though it imported it that would work in ember cli that would break under embroider so there's a bunch of cases where yeah we had to do some fiddling with with undeclared dependencies or tricks that we'd play with putting something in peer dependencies instead of declaring our own dependency on it that that that that took some doing to to get that all working another one is es6 that might be es5 module compliance i can never quite remember the the distinction between es5 and es6 modules but the idea is that the webpack static analysis of the code is based on stricter module resolution rules than ember's kind of runtime module loader or or or missed the the way the code gets transpiled into runtime modules so a lot of slightly incorrect imports um like for example i think this one isn't actually a problem but the example of the sort of thing i'm talking about is if a module has a bunch of named exports and you consume it by importing a single default export and then accessing the named exports as properties on the default export uh that you know that's that's not actually correct because the module isn't producing a default export it's only producing named exports i think i think embroider i think webpack might just give a warning on that one but that's the sort of issue that uh that um that we ran into in a number of places where just imports weren't quite right um then statically analyzable components so there's a whole section in the embroidery readme on kind of how to deal with it but you know sometimes a number we use the component helper and can play a little fast and loose where maybe one component gets past an argument that's the name of another component and then internally uses the component helper to invoke that component and uh and when moving to the optimized embroider settings so so by default uh there's sort of a baseline of of embroider settings but to get uh to a bunch of optimizations including route splitting need to uh enable kind of a higher bar of uh of settings that allows embroider to do more static analysis and one of those is is uh components so that embroider can understand and can part of it is being able to tree shake components being able to look through the templates and see what components are and aren't referenced so that it can leave out components that actually aren't referenced anywhere uh you know in an add-on for example um so it definitely took some fiddling because there were places where we were playing little tricks with how we with how we kind of dynamically invoked components that uh needed to to clean up um css and sas like i said in the article unfortunately i didn't keep notes on that when i was doing it so i don't i can't quite recall exactly what the issues were there but there was a there was enough differences between how ember cli kind of assembles css and embroider uh assemble css that we ran into some styling issues and had to shuffle some things around and then the big one the third-party add-ons because all those things that i just listed when they're directly under my control and my code i can go in and fix them third-party add-ons is you know i can't can't just fix it immediately so in some cases contributing fixes in other cases finding workarounds through webpack configs or embroider configs to um to sort of address all of those previous issues but in the context of third-party add-ons and over in the article that i linked to at the beginning of of the presentation i actually list out all the all the major ones that required effort and explain um what was needed that that's probably a little obsolete now because i know at least one or two of those have been addressed since i wrote the article but that can give you a sense of the kinds of challenges that you run into and then also maybe flag some specific add-ons that you might you know use um that that are problematic fortunately i mentioned all the work around so for the ones that for the problems that i ran into so hopefully that'll help some folks out um and then uh kind of my this is my uh my last slide before we you know turn it over to q a but my experience getting support so i found that the dev embroidered discord channel was uh was pretty helpful um uh there uh there were you know there's folks hanging out there that can share their experiences and answer questions some of the kind of core drivers of of embroider like uh you know ed ed faulkner and and uh you know and and rob uh and rob jackson are um uh are there you know but they're they're busy folks so can't reliably you know get get support directly from them but the the channel but but they do pop in and out and answer questions and so the the channel is i found was pretty helpful um i found that bugs don't always get addressed very quickly because again i think there's just a lot that's still being done on it um but i found that that pull requests get attention pretty quickly and it's relatively easy to get some support from from ed or from you know other folks in terms of shepherding prs through um and uh and yeah like i mentioned the core team was pretty helpful in providing advice for investigating and and fixing bugs um and i found that the embroider code base itself as far as diving in to just investigate and figure out how to work around something or contribute back a fix the embroider code base looks kind of intimidating but it isn't too terribly hard to kind of dig into and investigate issues once you know a little bit of time getting comfortable with where the pieces are but then my experience with with the code base was was pretty uh pretty positive and i did manage to contribute a few fixes back for issues that i was running into so um uh so that's all that i had uh presentation wise um and uh like i said i wanted to uh save time for for any uh questions that folks have so i'll open the floor to questions uh you're awesome thank you so much for support for the talk um and i maybe have like a question you already mentioned it that you and list a couple of like these already out like an article but maybe just like to give like a high level idea about like uh what uh kind of like issues people might stumble into when trying to optimize their own app and having to deal with like the party add-ons um sure as i recall the two biggest issues were uh were undeclared imports um so uh so places where an add-on would would depend on another add-on that depended on a third add-on and then the topmost add-on would import directly from the you know from the other add-on which you know i i've been in that mindset myself of like oh i know this one provides this one and i think of them as sort of part of the same thing but for a static dependency analysis that doesn't work so um uh so you know that there's the sort of you know you know in the kind of dirty work around realm webpack has a string replace loader where you can use regular expressions to actually rewrite the contents of source files that are being brought in and so i think for some of those you know it was figure out how to rework the the you know imports so that it actually imports it from a place that is available or you know something like that um and then the other the other big one partly you know partly because of some of the add-ons that i was using but uh add-ons like um what's the one uh so i'm using um ember validated form which they're working on updating it but it's pretty old and does dynamic component invocations all over the place and then i think ember basic drop down and ember power select have like a limited number of um of uh dynamic component invocations the the and and so that needed some fiddling there the nice thing about that is that the initial porting to embroider we do it without the optimized settings and so none of the dynamic component stuff you know really matters at first so it's like you can get running on embroider and uh and not be able to turn on route splitting yet but you'll still get the the tree shaking and and and uh you know kind of and and and those aspects of it and then can iterate towards which is the process that i went through and then can iterate towards you know turning on you could turn on the optimize settings one at a time i think i turned them all on and then it just it was almost all of them were in the component uh in the component realm um but uh but yeah those those were the main the main things that i that i ran into i'm sure there's a couple smaller miscellaneous that i'm forgetting but those were the big ones yeah that's so powerful thank you um one question um from a business perspective um was it worth it i i mean from from from my understanding you have a very interesting application that might benefit from that very very much right but um for the regular things that are just behind a login screen the admin interfaces that you tend to build with ember um what's your opinion there does it really make sense or is it better for people just to wait out obviously we want to try it right but does it really make sense for big applications to switch already yeah that's that's a really good question so you know i think there's two sides of it right which is how difficult is it going to be to move over and then and then what are the benefits going to be right and so i think you know how difficult it's going to be is probably directly related to the size of the app but also how old the app is because you know six years ago ember code is more likely to have things you know patterns that we all followed then that that that are harder to you know that don't match well with with embroider versus one year ago ember code right um in terms of the in terms of the value um i probably i so it was definitely worth it for us we got some immediate code size savings and then just a regular part of my life of every time we integrate some new third-party library figuring out how to make sure that we don't bring in all the code if we only need a slice of the code or something like that has just pretty much gone away you know so it was absolutely worthwhile for us i think had we not had some of those particular characteristics where we were especially concerned with the code size driven memory consumption which has something to do with our multi-window you know architecture and all of that i think it probably wouldn't have been worth you know 3.5 weeks uh of um of of of effort uh so if your app is as complex as ours but it's just yeah login screen and and then you know a bunch of web pages in one single browser window um then yeah i i would say probably not not worth the you know not worth the effort uh but there's i think those are you know curves that cross somewhere right the complexity of the app increases and the value you know the value of the benefits you can get increased and so you know are you are you above or below the line um yeah so i feel kind of funny sitting here pitching the you know don't put too embroider which is not what i'm saying because i think for a lot of really simple apps it's not that hard to to port over and then you know and then you're set up with it you're helping the community move forward uh you know and and move in that direction and you know get will get some some benefits you know i mean tree shaking you know in that case since ours is a desktop application download size isn't so important in terms of page load times but for you know for a web app it is so so that you know there could be uh could be that consideration also any more questions um first thanks ben nice to hear about your experience um and apologies if you already answered this in the slides or in your article and i hadn't picked up on it but i'm curious if um if the embroidery experience matched your expectations the expectations you had going in versus the end results if it got you what you were expecting in the end what you wanted i i hear like it's similar question but slightly different to the last one yeah um i i think the effort that it took was roughly in line with with what i expected it was maybe a little more but not not a lot more uh the end result um was uh i think a little better than expected um i think um the uh the the the tree shaking benefits the the the the code size reduction benefits i think i i my expectations of that were pretty clear because i knew how it should work with webpack and the promise of embroider saying you know imagine ember app but webpack and then you get all of the tree shaking and leaving out code that's not explicitly imported from you know that sort of stuff um when it actually got to route splitting was was when i was very pleasantly surprised that that was a really cool experience where i had all of the optimized settings finally enabled ci passed and then went to and set split it routes colon true or no it's not cool and true it's cool and then an array of the names of the routes that you want to be considered for route splitting and then started up my my app and there was one or two minor issues of lazy loading blah blah but it's almost it's like 90 percent true to say that i started it up and then just like magic my different windows only had the specific code loaded and uh and that by the way the route splitting because it does lazy loading so that's not that's not unique to um to multi-window kind of things but if you know you uh if if you do the splitting right then maybe your login page is in one bundle and so when your user first arrives it only downloads the login route and and its dependencies and then as soon as they complete and it transitions to the index route then you know it hasn't loaded the code for the index route yet and then when it does that transition it dynamically loads it so i i just realized i might have mispitched that as like the route splitting is the benefit to us was that was this multi-window um splitting but for any web app that that has those sorts of patterns where there's certain routes that maybe the user never visits or or they just visit later so that the initial page load can be smaller so that that was i was delighted by that and and how sophisticated it was and when i say sophisticated i mean that when i dug in you know i don't i'm not sure what i thought i thought maybe oh all the services are going to be loaded it's just the routes and the controllers and the controllers templates but but the components will all be loaded too or something like that but it really does you know in in a sort of dependency chasing manner starting from the route you know say okay this route is going to go in this bundle so let's find the components and the services that it actually you know references and by the way i think that's where i might have there might have been some dynamic service lookup or something like that that was that it couldn't analyze and so it didn't include the service and the bundle you know so so but i found that all pretty easy to to work around and and was very delighted by the end result like better than expected as far as route splitting as far as how easy it was after all the hard work was done and what a great result it produced very cool thanks appreciate you going into that okay awesome um yeah with this uh set uh i would uh kind of like conclude again like thank you so much for this awesome talk uh was like super insightful informative um and also thank you for asking questions um yeah and if we want we can also get another round of applause um it's like starting a bit weird on the call but still funny looks so nice to actually do that thank you so much um and with this set we are ready for our next talk um this one is by agar badir who has been working on a color blindness emulator in amber and will tell us all about accessibility color blindness and how accessibility plays into this in her amazing talk yeah give it a heads up to a god as well please [Music] [Applause] thank you thank you very much for having me tonight so yeah i'm very pleased to present you my color blindness emulator so i'm uh yeah i got padilla i'm a junior front-end developer i've been using amber for only a year and year and a half so i've been digging into that and also i've been digging into accessibility uh in general which was it's a fascinating topic so um i've been digging into that but also into sub topics such as um color blindness which is something that for me was really fascinating and i think my first question of course was how do people who have color blindness see colors how do they go online how do they have how is their experience when they i don't know when they buy something when they're on a platform and i didn't have a lot of complete answers to be honest i was checking on some um associations uh articles reports but it was it wasn't i wasn't fully satisfied so i wanted to dig deeper into that and maybe to see further than just like emulations of pictures of how people see uh sea colors i also wondered at one point how many people are actually caught up light and actually quite a lot it's only estimations but one in 12 men and one in 200 women are actually colorblind and the estimation on some resources are around 300 million people and i meant some additional calculation we actually showed that uh it goes up to 600 million so you know quite a lot of people at the end so i was like we we need more more resource so where is the information maybe i'm missing it i wasn't super sure so what i decided to do is to kind of emulate it myself and see if it would be possible to see how people with different types of color blindness yeah see uh see online and see see the word so colorblindness emulator enter the scene and what i started with first was to see if there were some um color emulators already available online so i actually found one from hell to you on github who used who is using a svg filter which is um also using css to call each types of color blindness so then to have different ways of seeing colors for eight eight types of them which is um quite complete and very very nice and in the demo from this person it's basically showing eight different results on a different picture so i saw this was like quite uh quite clear and i was like okay let's try to do that but for you know an entire page to see how uh we can have a full immersion at least online so what i did was um creating an amber application actually reading quite a lot uh chasing for a lot of different resources information gathering but also um sharing real life examples and mostly uh practice or counter examples to make uh the color blind experience a bit more tough to have a better awareness um and my my goal as well was also to aim to have a hundred percent accessibility for any any users uh checking out this project so for anyone using a screen reader for people using uh only keyboard navigation for mobile um so yeah try to to still have this um accessible part of it and yeah hopefully bring awareness uh for for my hand to learn more about this but of course for anyone interested to maybe use it as um as a resource place so this is how this looks so we have basically kind of a menu that is emulating those eight different types of color blindness and i can show you how it looks like here so uh we have here as i say like eight types and maybe to give a very very short uh definition um of them protonopia is basically when you have a red green color blindness and protein normally is a milder version of it so when you have um let's say protanopia or in general any colorblindness type that ends with nopia it's basically saying that some cones inside your eyes are actually missing so you see color in a very different way and when there is anomaly in a specific color blindness type it basically means that these cones are here but they are not working um at their full loss they could be uh defective or working um halfway so um this is another way to understand that those terms that normally are basically milder version of their color blindness types so we can have a quick look so in the first part i share a few definitions with a recap where we can have a look so protanopia red green color blindness definitely proto-normally shares a more milder version of it geoterranopia also has this kind of red green color blindness but also shares it with with yellow with purple with a gray as well the green caption is actually quite gray when i have this emulator on and jutera normally again as a milder version the some some colors are a bit more faded like the green the green red and tritonopia is quite different where we have a weird color blindness around red and yellow where yellow looks like pink literally but also with green blue and purple treated normally again very milder version and achromatopsia is literally when you do not see uh any other colors if you only see shades of gray and a chromatomally a milder version which is a bit more like a a dull version of the colors we see as non uh colorblind people and so yeah that's um a pretty cool way to see a lot of different types on one resource what i added as well was also different examples that you might already know maybe from from experience around form and communicating with colors only which is not really useful when you don't differentiate green and red or when you are using links styling or buttons to basically say okay i want to access it but i have no clue where is the button oh okay and additional things like color contrast which is like probably the most known um as well in terms of color blindness but also when you are online shopping with color pickers do you see what kind of colors they are here ah not really so that's another thing to think about and i think my last example is about pie charts infographics um there are ways that are really not accessible for different types of color blindness so definitely not not even able to to use it so i added more resources in um there are more resources in additional links so feel free to to check it out later on and yeah i also had it all my resources uh books definitions articles extensions applications if there is one that i would highly recommend is the color accessibility workflows by gary kawadi who um gives very simple definitions uh very interesting research uh from um from the the medicine industry domestic side and yeah um overall yeah feel free to dig into that it's definitely a very very interesting topic and yeah i also wanted to say thank you for the person who helped me through this project at different stages so leandro nalvax populai and mintai mia for the early stages around my fruiting issues up to some content security uh policy ads on that were not really working well so thank you to uh to you three otherwise i think i wouldn't be done today with this project so i'm again really really appreciate this super cool amber community helping out and yeah as a next step i think i would love to see if i could implement this project into a chrome extension to enable people to just um yeah emulate this in in any web page you would like and give a bigger awareness on uh yeah all the different types of colorblindness and also maybe to test this using an extension and see where they can improve uh the product so yeah thank you so much you can uh definitely check out the website on colorblindnessemulator.netflight.com my repo is under github i got padilla and yeah if you have any questions i'll be happy of course to to answer but in general i can share again the uh the presentation and the project and yeah thank you very much yeah thank you so much for this awesome talk um i also would already have like um a question right off the bat you already showed like a couple of like really interesting examples of um yeah typical elements you could see like a web page like for example like the bar charts and like also like the forms that are completely color coded that are inaccessible for people who are colorblind and i'm kind of like wondering especially like with the charts like uh what would you say would be like common recommendations to avoid um this inaccessibility from what you have researched so far yeah that's a that's a very good question so what was usually recommended especially for pie charts so um when you have evolution infographics or pie chart to use i don't know if it's called that way but you have texture to basically differentiate let's say a dot texture another one will be more around rectangles or like patterns sorry to use patterns instead of only relying on colors and i think it would be the same for if you want to show evolutions to have like dotted lines longer dotted lines uh or to make sure you have actually a color contrast between all the colors you use it's very tricky when you have lines in general um but i think for pie chart if you use a very strong color contrast between i don't know uh something very light gray something dark and if it works out i guess if it works like for a chromatopsia i think it's a win because then with other colors at least you have some some differentiation so yeah having patterns having either um different texture of lines for evolution is definitely a great way to make it accessible yeah thank you that's so helpful any more questions also feel free to use the chat if you want to post any questions i think there is also another recommendation from gonzalo from your question jesse which is uh so to use bar charts uh which is another way to make it accessible um because like when you have uh captions on infographics it makes it um way more difficult but with bar chat i think you can rely on on a straight line and have a better understanding that was just reading the comment section yeah that makes a lot of sense as well thank you um okay um if there's no more questions for this then again thank you so much for this awesome talk has been super insightful and um yeah kind of like also me personally gave me a much more kind of like awareness that uh it's like good to actually test for colors and um how we actually apply the webpage before actually shipping something to make sure it's not color accessible so for this thank you so much um and with this we have already uh come to our kind of like short uh break i can maybe also quickly share the screen again uh to show everyone uh so i would suggest we can maybe take like a five to ten minute break and we'll see each other again at the full hour so 11 a.m pacific 8 p.m central eastern time and yeah you know what i mean so yeah feel free to grab a snack grab a drink and we see each other again like at the full hour [Music] foreign [Music] [Music] so [Music] [Music] [Music] so [Music] foreign [Music] [Music] foreign [Music] [Applause] [Music] wow [Music] you [Music] [Music] so [Music] [Applause] [Music] oh [Music] my [Music] um yeah i'm very happy that i can present this to you today um i'm francesco i really like to travel and looking forward to do that again which is also why i'm maybe only i don't know 75 fit today because i got my second covet vaccine shot yesterday so um yeah i could feel better but i'm happy that i feel well enough to hold this talk at least um i work at febscale which is a small company we build software for coffee roasters you can imagine this roughly speaking that we collect data from all the machines in a roasting plant sink it into the cloud and then we have a cloud application where you can see your kpis your production data do quality control and things like that i lead the technical team there and i'm also heavily involved in actually writing the front-end application our stack is an ember app which we use for the front-end it's a fairly up-to-date octane app we have a java based graphql api and a little software called the cloud connector which runs on premise in the roasting plant which is built in c-sharp i will be focusing on the ember part especially on like how we communicate with our graphql api for that we use ember polo client which has been around for some time and works quite well for us i've seen quite recently there is also new ad on glimmer apollo which also looks very nice i have not looked into it in detail but generally what i will be showing you should it should not really be tied to ember polo client itself but be more like conceptually how we handle things so this talk is not really about graphql itself so the goal is not to really explain graphql in detailed a lot of resources on that i just want to give a very short overview for those who maybe don't know anything about graphql um you might be more used to working with rest apis with something like amber data a rest api where you have an end point per resource where you may get a post or put requests to do certain things on this end points in contrast graphql has a single endpoint where you just always post to and the type of action you're doing is defined by the payload that you send and you can send either a query or a mutation to either fetch data or to do something the way this works is that you have a static defined schema where you have types which is basically a model so you could have a user type which has certain fields it could have an id a name an email maybe it has a company relationship and maybe it has a roles relationship for example when you now write a query for graphql in your own application you can basically define which fields you want to have so in the top left code box you can see we want to do a user by email query where we have one variable which is an email and what we care about is the id the email the name and for the roles relationship we want only the id and the name as a simple example on the right side you would see the payload that you would get for such a query it's basically a pojo in the structure that you defined and on the bottom box you see how you would actually invoke such a query with ember apollo client um basically amber apollo client provides you a query manager which is basically a service kind of and this has a query and a mutate method that you can use and you can pass it a query and variables and then it will invoke this and it will return a promise that resolves to a pojo so very high level overview of graphql if you are interested in learning more about graphql there are a lot of great resources out there and i can recommend it we have been quite happy with it one thing that might also be good to mention is we have a graphql api and we use ember apollo client so what is apollo compared to graphql apollo is basically a specific implementation of a graphql client this is non-ember specific i think it's mostly actually like the normal apollo client is built mostly for react i think um but you can easily use it in an ember app as well and what apollo client basically does is it brings certain things on top of just a basic graphql functionality and with it especially also the caching so if you are used to maybe amber data this brings a certain level of caching out of the box and it also has its issues basically you fetch records by id and then these records are stored in the cache and you can basically fetch them from there without hitting the network again if you want to apollo also has something like this out of the box and the way it works for apollo is that a full query is cached this means that if you have a certain query with a certain set of variables the first time you do it it will be cached when you have the same query later it will not hit the network again but just return you the same response than before this generally is nice and works well but we found it to be um potentially tricky when working a lot with mutations so and also with ensuring that no data becomes stale because our application can be quite long-lived you can imagine a person in a coffee plant pulling up our web application and just having it open the whole day now the way that apollo caching by default works is let's say i fetch a list of tasks in the morning and then 10 hours later i fetched the same list of tasks again i will get exactly the same responses before but i probably just want to hit the network again at that point so this is a short example of how this caching works in apollo basically just description of what i just said so the first time you have a query it will hit the network and when the promise resolves you have the pojo now when i do exactly the same query with exactly the same set of variables again at any point later it will not hit the network but just give me the same response again if i use the same query but with a different set of variables it will hit the network again and then cache this again so the cache is really per set of variables and query now if you bring mutations into this you can quickly see how this can become a bit tricky so let's say i query a user i want to get the user by email for from jessica fabscur.com now i have a user object at some point later i run a mutation i want to update a user and i want to update my name to francesco smith let's say now if at any point later i rerun the query to fetch my user by email it wouldn't necessarily know that i have run a mutation in the meanwhile and it will just return me the same user that was fetched initially which is not what i would want here in this case i would just want it to basically hit the network again so apollo does provide tools to work with that because obviously it's a common use case so the way this is normally handled is that with a mutation you can have kind of a callback so when the mutation is done you get access to the cache object more or less and there you can basically manually update the cached responses for the different queries that's quite powerful and of course can be very performant because you can really avoid any duplicate lookups or network lookups but for us this became quite annoying quite quickly because you have to write a lot of kind of low level code or it feels kind of low level let's say you have you update a username then you need to fetch any query where you have ever fetched a list of users and make sure to update it accordingly etc etc so it's possible but for us it felt kind of like not an ideal world solution we wanted something where we define more or less the rules of how we want the caching to work and then we don't really need to think about it anymore later what we ended up building is a pretty thin layer on top of ember apollo client which allowed us to easily define how we want caching to work and to do that we basically only use the fetch policy that apollo already provides so for any uh query you can define the fetch policy which by default is cash first cash first means if a cash exists it will return the cash if no cash exists it will hit the network and then cash the response so what we ended up doing is made a small function that determined if a certain query should be cached or not if it should be cached we would just set the fetch policy to cache first and if we decided it should not be cached then we would set the fetch policy to network only to ensure it will always hit the network and then we more or less kept the map of the different queries and when they were being made we do not manually work with the apollo cache we just we do use the apollo cache but we do not directly interact with it only over the fetch policy and when we run a mutation we're allowed to define a list of caches to clear basically i will show some code how that works so the usage is relatively simple the way we implemented it is we have a service per entity for example let's say we have a user entity then we would have a user store that has all the methods for interacting with users we would have load user slot user create user delete user update user for example these store services use the store manager which is a shared service which is basically this syn repo on top of apollo way you would then invoke it is more or less similar to the way you do it with apollo client most of the things are just passed through the relevant thing really here is the cash entity and the cache id so we allowed to give cache entity which is really basically a name space for how to store this and optionally an id and then in you can also define a cache seconds which is after this amount of seconds we want the cache to be invalidated this means for example we say load users after 300 seconds if this query is made again we always want to hit the network no matter what happened before and this basically helps us to avoid stale data something like this might not be relevant for every use case but for us it works quite well now if you have a mutation it's pretty similar but instead of defining how you want to cache it you can define a list of caches to invalidate and you can define either just a cache entity which will invalidate anything where no id is given so basically any list query let's say and you can define a cache entity in combination with an id so in this concrete example after we update a user we want to clear the cache of any query that basically returned a list of users and we want to clear the cache of any query that returned this single user with this email as an example how does this work below the hood at the end it's quite trivial trivial i would say we have a method that checks if the cache should be used i will show this afterwards and then we set the fetch policy either to cache first or to network only and that's really basically it the key thing then is how you implement the method to check for cash usage this might depend a bit on your business logic the way we have it is we have a store cache which is basically a map of maps so it is a map per entity type and then each of these map items has another map per id more or less so we can always look up when was the last request made for this given id or for this given um name if i don't give an id and if this is old i can update it and else i just you know keep using the cache and then on the other hand when i run a mutation all we do is clear the cache for this specific entity type so the next time the check should use cache method is run it thinks that this method has never been run and it will always try to hit the network that's basically it how we handle caching it of course might lead sometimes to a bit more api requests than necessary but it is a really hassle-free solution for us we can always just um use the store manager methods and not think too much about or do i need to somehow force this to reload or something like that but it will just always go through the normal path when i invoke something now the second part i want to talk about shortly is how we then actually use our queries in our application and for that we use ember could get used to this which is a really awesome ad on if you haven't looked into it i would heavily recommend to do that we use it everywhere an application now and it has really changed how we write our ember applications amber could get used to this provides multiple different things i will be focusing now on resources so resource is a kind of helper like primitive that allows you to work with asynchronous things in a reactive way the key thing is it has a value property which returns something which you can then use and this is auto tracked so you can really return whatever you want in our case we have a value that returns its loading data and is error which are normal tracked properties now the interesting thing is the life cycle hooks that a resource has so it has a setup hook which is called whenever when you call it the first time and the teardown hook which is called when it should be destroyed the normal behavior when an argument changes it will tear down the resource and set up a new one you can also provide an update hook which will then instead be called if an argument changes you can have positional and named arguments and yeah it behaves mostly like a helper in that every time one of them changes the setup or update hooks will be called again so this is a really straightforward example on setup we want to use ember concurrency to basically use a service method and set data to something or if there is an error we set the error property and then the normal tracked behavior will lead to value being updated and value is then what will be exposed to the application you invoke this like a helper we group all our resources in a app slash helper resources directory but you could put it anywhere in your helpers directory and it works pretty straightforward the really nice thing with that for us is that it kind of it doesn't force you but it really makes it obvious to always have loading and error states because like whenever we create a resource somewhere the syntax is always the same it's always if resource is loading as if his resource is error else it's a success and this makes it much easier to not accidentally kind of drop some potential error state somewhere under the table before the really other options if you want to do something like that is often you might have a method let's say load user which you can invoke from your constructor which works but a you need to make sure to catch errors save the error somewhere on the component and also expose this somewhere and b the tricky thing is what happens if you want to be reactive what is if the email address changes um if you have it if you invoke the method from a constructor this will not work very nicely you can then use something like the dip update um helper in your template but this is also kind of a heck really and not a nicely reactive solution and with the resource it's really pretty clear what's happening really easy to follow and the added benefit is also you can also use them in not only in a template but you can also use them in a javascript file there is an add use decorator that you can use and then you can also reference the value normally in your component and it will react to any changes in a reasonably followable way and basically with these two things is what i would be consider our thin layer on top of graphql it works well for us it might not work well for everyone but i hope there was maybe something interesting in there for any of you i will also share the slides with the code um you can look at it later if you want to if you're interested in some of the code maybe and yeah if you have any questions feel free to reach out yeah awesome thank you so much for this awesome talk and are there already some questions here in the audience just one question uh regarding rest versus graphql um not sure why you are using that um if that addressed something or just because it was the just a nicer thing than rest right um does graphql provide any value on top of what ember data would have given you or is it just a new cool kit on the block that everybody wants to try so i would say for us the decision to use graphql for this project was two things one is we have been using a json api before but have been a bit i mean frustrated would be over stating it but there were some proposals that were really promising but they have been basically pending for years um like um what was it called like creating multiple records in one request and things like that which were quite important for us so we were kind of not feeling 100 percent sure about how quickly the progress would continue for json api that was one part um and the other thing is our application is very in many ways it's not that resource oriented we work a lot with kpi computations that happen on the server and you can model everything kind of with rest but for us it often felt a bit hacky to kind of make up resources that are kind of grouped and have sort of relationships and things like this it felt cleaner for us if we say okay we have graphql we can for every request define which things we want because it's also always a bit tricky sometimes i want um a single kpi sometimes i want in the same request to maybe include some other data and graphql makes this very easy so i have to say i have been quite happy with it but yeah it's i don't think there's anything it's not necessarily better than rest it really depends on your application or how your data is made up makes sense thanks for watching uh yeah here in the chat already people commented that's like a really cool uh cash publication that you also have like for the project and i was also wondering in this regard like do you already see some more things that you want to add to this kind of like implementation right now or do you think you're already kind of like good to go with what you have i have been thinking about kind of extracting this into and it on at some point um it has been in flux a bit and also in parts is a bit specific maybe to our application so we will need to see how to kind of extract this out but i figured it's not necessarily only specific to our application i know that glimmer apollo that i shortly mentioned in the beginning i have to be honest just skimped the me quickly it seems very nicely documented and that is built on top of resources by design which i think is a cool concept you could use the same caching strategy there for sure because that's just normal apollo caching stuff so yeah i think my next step would probably be to try to extract this into an addon make it shareable possibly and then see where it goes from there basically yeah gotcha thank you any more questions here in the group if you want so free to use the chat if you want to post something i think i can ask one question up on people i was wondering the caching storage is quite interesting i was wondering about how that affects the testing so how would i test that the data is never stale you should have this caching mechanism actually the nice thing about this is that it you can really just test it in any integration or application test by um if you use something like msc live mirage or something like that if you change any state in whatever you use as your mock api and then you should be able to see if the data that you actually have your application has updated correctly because if you have not set up something for example the common cases i have a creation form so i have a creation form for some entity and then after that i'm sent back to the overview page i want to make sure that the thing that i've just created is actually on this overview page because if not it would mean that my list query was cached and has not been hit the network again and this is actually quite straightforward to test by really just checking is this on the page or not so that works quite well and for feedback uh you showed us a static value for the cache seconds and i was wondering what i thought of dynamic value so for example there might be certain hours already know from experience uh people want to make more requests would this be possible it's definitely possible i mean the the function to check if the cache should be used is quite primitive at the end of the day you could add any number of variables in there to check if you want to skip the cache or not so it would definitely be possible to also introduce other like variables to define if you want the cache to be cleared or not thank you any more questions from the group if there's none then yeah thank you again so much for the successful talk um i learned a lot about like um yeah first of all like if i get used to this didn't know about this before actually also like some people also wrote in the chat that they are working with it right now so this sounds like really cool and also what you're doing like a fab school with it so yeah thank you again and um and with this said um let's get to our final talk for tonight uh very interesting talk also about like reactivity and reflective systems in emberjs by michael klein and clements muller so give it a round of applause and looking forward to this talk hey hey um yeah so welcome to our talk on the development of reactive systems with emerges and the goal of the talk is nothing less than to revolutionize the way that you think about application architecture with emma suggest for everybody who's who's waiting for code samples please don't be sad there won't be code samples in the talk but um everything that we tell you um can result in executable code but this is not the main focus of this talk um the focus of this talk is the mental model but rest assured you can actually use this directly in your code and the end of the talk will include some links that point you into the right direction also clemens and i are super excited about the concept that we're going to present so um always feel free to just ping us on twitter ping us on discord or shoot us an email we're super happy to and excited to help you out with this concept um who whoop who are we and um why should you care what we have to say um we are i'm michael and my co-presenter is called clemens you can find us on the internet via our handle level boss mike and uh pangradz we've been doing mr.js development for basically since emma was a thing we philosophy over amber a lot um and quite honestly we can't remember who started out we didn't know each other back then but um yeah we basically have been using emma since it was a thing and before that we were interested in spot core um because we have because we have um so much experience building apps with emberjs we also run an amberjs consultancy called effective amber where we can help you and your team build with ember gs um even if you're not interested in getting help from a consultancy and you might also be interested just looking at our homepage because there's a blog and there might be some interesting topics discussed there as well but to keep um things moving forward um before actually telling you about the concept um that the reactive systems concept um i think it makes sense to actually start from the beginning and explain to you our journey how we came to this concept right um although we have had a lot of experience with ember gs working with emojis before and implementing a lot of applications with it um sometimes with client-side development although we are using the best framework which we are still confident that ember is the best framework um we have some experience with other frameworks as well but in our experience things just get more complicated if you don't use ember right so um although we had so much experience oftentimes we ended up in situations where stuff just hit hard right and client side application development felt hard to us at some points especially if you're doing some more intricate stuff like um offline data or um collaborative editors um stuff like that but even then if you're not implementing stuff like that and even if you're only just dealing with some stuff like drop downs um custom drop downs or type of head components stuff like that and you oftentimes end up in situations where things get complicated quickly and we couldn't really tell why that was the case um so we started thinking about that uh more thoroughly and if you think about it um from an architecture perspective mr.js on top of its convention that it gives you amber cli the the add-on ecosystem and also the ideas that it has about routing and it really doesn't provide developers with too much guidance about your application architecture right the only paradigm that you tend to hear a lot and what you always tell people when they ask you how to build stuff and we always tell them hey yeah just used data down actions up right because that's basically the only architecture paradigm that we have and um the the idea can be summed up pretty simply um so when in data down actions up you have some kind of application state whatever that may mean um and you pass down that data or state into the template layer and the glimmer rendering virtual machine then takes care of rendering the template for you and basically spits out some html and that combines the data that you passed down and the template that you created and then whenever you want to change something in your application or you want to enable users to change something you send an action up right doesn't really matter how how to do that because in the back in the days we had um we really had action bubbling but um in the end nowadays it's a little bit different because we really pass down action handlers and and call them directly but in in essence you pass an action up and then some action handler does something and updates the state right um we can't really tell you where this originated from but we have an idea that this originated originally in the react ecosystem or at least that's what we heard back in the day when when when this pattern was introduced into the ecosystem um before that we had to weigh data bindings and observers and this was obviously a better solution for a sane data flow and then the two-way data bindings and the observers and um this was like it was introduced to the ecosystem it's like yeah this is the what the react peoples are doing react people are doing it's working much better than what we're doing so basically let's switch to that and um that's fine and all but um and and that's fine and it's nice for data flow and if you take that to the extreme basically consider every your entire application and with that paradigm you end up with a um with with the idea of your application being a black box right that takes in the state input and then transforms it in some kind uh some some kind of form and then it spits out an html representation which is basically your ui app that you want to present to your users and if you think about it that's pretty much a back-end view of the world right it's not that different to um to what we're doing with server-side rendering we're just using inputs transforming them in a black box and then splitting out outputs which in our case is an html representation that gets rendered in the browser and the nice thing about this paradigm is that it's makes you sound super smart when you um talk about it um and it sounds very very elegant right elegant right it's basically you your application is a function over the state that you want to show to your users and the result of that is your ui um unfortunately when clemens and i were discussing this we realized that this sounds super cool and it works if you think about presentational components but it doesn't really address the complexity that is client-side development right because if you think about it the complexity when developing images applications really doesn't lie in the passing down data to some kind of template layer and then having the glimmer vm re-render for you because glimmer does that for you automatically and also the complexity doesn't really lie in hooking up event listeners and then firing at actions when somebody somebody does something in your application like clicking a button the actual complexity lies in the squiggly part over there not a straight error like we had before but really the squeaky part where you um you actually need to do something in the action handlers right and that's the complex part um at some point you actually need to do things and you actually want to update the state but updating the state isn't really trivial because in client-side application development just so many things can happen at the same time right um when francesco presented this idea of resources to us earlier and this is a nice idea so basically yes you could create a more solid solid architecture where you create these resources and then these resources take care of updating stuff for you or you just pull push pull stuff out into classes and these things then update but the actual complexity of just figuring out what needs to be done and what is happening at this current place and time isn't trivial and this is the typical stuff that you see even with the most even some most simplest things like an async button component that you that triggers an async request when pressed but you actually need to manually keep track of the fact that hey the user actually has clicked the button already and we don't want to se trigger the same async request again um while uh request is already in flight or you actually might want to do that and yeah you you it's your job as the application developer to keep track of that and that just gets overwhelming very very quickly and um the the thing is that data down actions up really is a nice pattern right it sounds cool um and especially the react people um the react ecosystem basically tells you um hey there's no issue here um you just really need to embrace this pattern because your ui is the state is the is the ui is the result of a function over state in time right this is literally what react is telling you and basically what what most people tend to tell you is that yeah some somehow this works um the and this is not particular hard to do with with ember or react or swelt or view it's all the same with all client-side frameworks all of the climate frameworks has have embraced this pattern right passing the state down and then triggering actions up when you want to change the state um so this is a nice view and elegant view but does it really work right this is also a popular opinion if you ask people about or basically just tell people hey i'm a client-side developer things are hard i'm not entirely sure why um do you have an idea and the the stuff that people tend to tell you especially back-end developers are like yeah um no it's really this transformational thing you just need to do that over and over again you need to be able to render all the time and it's just hard for you because um the client-side developers are aren't that bright um the real programming happens in the back-end layer and we basically don't know what you're complaining about it's really not that hard um client-side developers might just be not bright enough to solve this issue um clemens and i thought about that a little bit and we didn't feel like the amber js ecosystem was super stupid or we were super stupid so we tried to look into the um little literature um and basically try to find out if anybody had encountered this issue before and might have proposed some solutions to this right and we were lucky while skimming through the literature we found this paper and this paper is called on the development of reactive systems and because it has reactive in the name um we quite we got quite curious right reactivity is um all the things that you hear when talking discussing client-side development so that sounded relevant to our interest and um reading through this paper the the situation that the author david ray describes uh back in 1985 um really sounded similar familiar to us right um david really described in in this paper describes the the fact that he feels like there are really two types of different systems um and one of them is much much harder to implement than the other one and the two two types of systems that he's talking about is a transformational systems and b uh reactive systems transformational systems we already saw that that's basically this f over state equals ui um portion and um the then he goes on and discusses what he feels like is a reactive system right and this sounds very very familiar if you come from the client side he defines a reactive system of some kind of um state system that has stateful right it has state in itself and then um it continuously needs to react to internal and external events so if you're a front-end developer this sounds very very familiar to you and harrell argues that in contrast to the transformational systems a these are much much reactive systems are much much harder to implement and b they need to be modeled totally differently plus you actually have to have a completely different uh they're just a different set of system right so in contrast to transformational systems where you only have inputs and this black box that converts that to outputs you actually have a stateful system that basically needs to react to internal and inter external internal stimuli all the time also this kind of system needs to be able to respond to interrupts like high priority events for example if you're a client side developer you might have run into situations where the user did something in your application they tried to submit a form but now they are navigating away completely and you want to cancel the request or something like that right so you need to be able to respond to interrupts also the state of the system represents some kind of current mode that you're in and this mode depends heavily on the stuff that happened bef on operations that you did that occurred before the the current time state and time right um also a lot of things can happen in parallel so again we read that and we felt like yeah okay this is definitely what a client system is and um and we read we had we read on um because the nice thing about this is that with that idea of a reactive system you can actually now upgrade your idea architecture idea of data down actions up and you now finally have an idea of why things are so complicated and they feel much more complicated than what uh the the um what people tend to tell you when they talk about this transformational system that you're that you're apparently building right um this the the the image that you see on the screen now is basically our new idea of the world where we're like yeah okay um we're dealing with a reactive system and this is where the complexity actually lives right so we actually need to find out how to model and how to build this reactive system now and what patterns exist on how we can deal with the fact that we're dealing with a reactive system and lucky enough for us harrell proposes a solution to that in his paper and he states that and this is a pretty huge takeaway from the talk today he states that a reactive system is a totally different kind of system and it needs to be modeled differently and a practical practicable way to model these types of systems is to do that based on states events that occur in the system and transitions that happen based on the events that occur in the system and also side effects that can be triggered while transitions between states happen um he also argues that which which the react people are always telling us um or that might be something that react people would tell you then if you talk to them about reactive systems is that hey mathematically speaking a reactive system is just something that like a transformation that acts like a transformational system but it needs to needs to be modeled as a transformational system with a second input as the current time right so basically this is the continue we need to be able to re-render all the time idea that we that react uh proposes interestingly enough in the paper from 1985 and harel states that and yes you mathematically speaking you could argue to do this but in practice it's just impractical and prone to failure because it just gets too complicated and a much much better idea to model these kinds of systems as i said based on states events that happen in the system transition between states and that happen based on the events that occur in the system and side effects that are triggered on state transitions and this is very cool because now we can and um i'm sorry to go back a little bit and the thing that you see on the screen here is called uh um is a visual language that harold also comes up with on how you can actually visualize the state transitions and events um pattern and the thing that on the screen is called a state chart right um it's really not too hard to understand if you already know state machines but it's more practical to work with because state charts in contrast to state machines actually support the idea of nesting parallel states and um yeah orthogonality in general so um they're much much easier to work with than than state machines um so the idea is to actually model your reactive system or how your reactive system should behave beforehand right and um basically move all the complexity into the model of your reactive system instead of having to keep track of all the complexity yourself inside of these action handlers that you call so our um architecture idea of an mr.js application has transitioned quite a bit and it has transitioned to this so in the at the top of over everything there's this idea of the reactive system that we model explicitly and this reactive system has state that we pass down into the template layer glimmer takes care of rendering the state and then whenever something needs to happen we just send an event to the model that we created before explicitly and this model takes care of figuring out what needs to happen next and if a state change should occur um we don't propose to which which might be important here we don't propose to think of your entire ember application as this one thing that you model explicitly in this view super huge state chart but harrell explicitly states that um a reactive system is made up of other nested reactive systems right and if you're from a in if you're dealing with front-end applications these smaller reactive systems you you can consider components smaller smaller reactive systems that in the sum of all things make up your reactive system in addition to the actual application behavior that you want to model so um this is a nice idea now right so we can actually just send events to reactive system and the reactive system figures out what to do next um but why is this now so revolutionary and why does it make it so much easier to model complex behavior and the reason for that is that it doesn't really matter what things occur in your system everything can be treated as an event right so um things like um a websocket event arriving or you can navigate or online change the event happening it's really not you you really don't have to think about how to handle that anymore you just model that explicitly and send the specific event to the to the model of the system and the system reacts automatically so the only thing that you have to do is basically model the system and then send events to it based on what happens in the ui from the internal or in external stimuli so that's got much much easier and it basically um gets rid of the entire complexity of front-end development um especially if you're dealing with behavior right um and i really said it gets rid of the complete complexity and it just makes everything easy basically and so you might get the idea that hey if that was so great and if that has been introduced 35 years ago if everything worked great with that why isn't everybody using that and why didn't nobody care about thinking that this might be a good solution for client-side application development and to explain that in more detail i want to give it over to clemens um because he has yeah he has he has thought about that more thoroughly than i did so you should see my screen right yes okay cool all right so after this short break um and letting this rest what michael basically was saying is um that we are proposing a a way to solve the inherent complexity and we're dealing with in the front end if this is such a groundbreaking way of thinking um how come this isn't used more vitally in the ui development how come this isn't talked about more is this maybe over engineering or is treating it as a reactive system making it more complex than it needs to be isn't all this relevant for embedded systems and maybe rocket science only and it turns out we're not the first one to propose this approach for frontend development this has already been discussed 22 years ago in a book with the promising title constructing the use interface with state shots by ian horox in his book ian horox proposes a methodological approach for developing user interfaces by using the tools that michael was talking about in the first half of the presentation so what we are doing basically is only to repeat what somebody said 22 years ago who repeats what somebody said 38 years ago we're merely standing on the shoulder of giants and by the way this book is very difficult get to to get so if you have a chance to get a physical copy of it you should buy it it's well worth the investment so we're now at the point um where an argument for reactive systems has been made and the way to describe them by state charts um this has been introduced um at this stage we always hear the same concerns um the most common response is that it's too too complex and adds unnecessary complexity a stage chart describing a relatively small problem or even a supposedly simple form abstraction can look intimidatingly complex our argument is that the state charts only make the implicit complexity of your system explicit and just because you don't want to see how complex your app is and how its behavior is doesn't mean the complexity isn't there also we're dealing with reactive systems remember that's what we've learned and they are inherently more complex than transformational bonds another concern we hear is that folks don't want to code and they want to code and not draw diagrams and to us this is an issue of development being only a part of engineering thinking about the system before it is coded helps his understanding of such a system and getting a better answer to the question of what it is we're actually building also as michael pointed out in the beginning you can use state charts programmatically so a stage chart describing the behavior can be used directly in code but this is not the the scope of this talk but yeah we'll get into this at the end of this talk and talk about it a bit more another concern we're hearing is that not another tool and we say that the thinking of the application as a reactive system and describing it with state charts is not another tool it's a correct mindset on how to think about the problem you're solving and even if stages aren't used in code again thinking about the system and describing it using the correct modeling language already helps with identifying edge cases a prime example for this would be the question of hey what actually happens when an error is happening in this state right here and a state chart makes obvious if transitions for example are missing and this brings us to the last concern which says that bottom up approach is fine so this is kind of analog to the point above about wanting to code and not draw diagrams coming up with code describing the behavior in an ad hoc way is riddled with bugs and hard to maintain and often breaking in mysterious hard to track stone ways having the behavior expressed visually um is a much better way to understand what's going on and within if the behaviors sprinkle around in code it's much more difficult to reason about so a visual representation trumps a textual one a state chart says more than thousand lines of code alright so to recap we talked about front-end applications being reactive system and state charts as a way to model them everything was quite theoretical for now so this is an ember meetup let's talk about how this is used in amp applications we told you that most complex apps can be modeled with this approach one of the most complex apps we know in the mbox ecosystem ecosystem will be docked in the next slide um it's a complex app because um it's not so trivial to implement um such an app in the yeah in the amber framework alex mciner as you might know he asked the question of how a certain type of application would be developed using amberjs the blog post is called ember rideshare and as you can see it's from 2017 so four years later but it's still an opening issue so let's take a look um for the uninitiated who don't remember exactly what that four year old blog post was about so the blog post basically talks about an application similar to uber or lyft where a user logs in the location of the user is is determined then a map is shown with nearby drivers the user requests the riot he's waiting for that the right is assigned the driver then he awaits the big cup eventually gets picked up arrives at the destination and yeah basically that's the flow of the app and what alex outlines in his post is basically three issues which i'm gonna summarize on the next slide so the first one being stacked routing or navigation stack so basically this means that such an app would have a stack where screens or frames are popped on and pushed off from this stack this pattern is seen mostly in mobile use interfaces and he argues that such a pattern is hard to realize with manila ember using the conventional router infrastructure especially if you want to persist that stack yeah and getting back later the second issue raises is that urls are not so first class so alex argues that only about 20 of such a rideshare application would be accessible so only about 20 of a page of the pages of the writer application would be accessible at any given time depending on which state the app is in so an example of amber writeshare the user can't be in the request and you write route when a right is currently active and the question is where to put such an can i be in this route logic without having duplication sprinkle around in various before model hooks or whatever or however it is solved and this gets even more complicated when the server can send updates which need to be handled locally as well and this brings us to the last issue mentioned in the blog post being the server-side state changes so it's easy for front-end applications to consider the user as the sole originator of state changes but there can be state changes which are not bound to actions made by the user but instead are coming from the api so an example of amber rideshare we might need to navigate away from the driver's detail view when the driver became unavailable or we might need to show the next route when the rider arrived and this is depending on where the user is currently at the moment and yeah and the blog post calls for solutions for what alex calls so-called server-side driven apps and we propose that considering it as what it is then we erective system this helps modeling and solving the race problem let's ignore the stacked routing for now and only focus on the two main issues about the url and the server-side stations changes the issue basically is that the routing hierarchy and the url define what is rendered but don't offer enough flexibility when a state change or an event doesn't originate from the address bar or the click of a user so if you think about the amber writer example as a reactive system you can describe it on the high level as being in two states so in the first state the user is unauthorized unauthenticated then he logs in then he's in an authenticated state and then he can log out when we kind of zoom in into the authenticated state this can be refined into basically initially the user or is we're in a state of geolocating so basically getting the location of the user once that happens successfully we are in the state of showing the map for example and if the location fails for whatever reason we are in a dedicated era state and once we got the location we are in the state where we show the map and this can be further refined to um the following so initially we are ready then the user requests the right and then we are basically in the request write state in this state what can happen is basically for example that no driver is found so we go back to the ready state if we are requesting a right and a writer has been assigned then we go into the next state which is basically awaiting the pickup in this state for example uh the driver which was already assigned could have cancelled so we yeah we go back to the real estate or the user might decide to i want to cancel the right so he wants to cancel it we are because we want to confirm the cancellation by the user we are in a dedicated state let's call it councilwrite which the user can abort and be back at the waiting or a board uh really canceling your packet ready and in the happy path um when the user was awaiting the pickup and he gets picked up we are in the writing state and after we arrived we finished it can show a summary and then we can go back to the ready so we can zoom out again and see a whole behavior of the the rideshare application this diagram is easy to understand it basically just puts the textual description of the writer app into states and adds events between them it might seem a bit convoluted but the writer app apparently has some complexity and with that we're basically done describing the behavior of the of the right share system as we said before so we don't include the code samples since this talk is mainly about the mental model itself but you can use the diagram and translate it into executable code we plan to implement this as a case study with accompanying blog posts which go into greater detail but yes it's not again not topic for this talk so let's circle back to the state of the problems of amber wrightshire so since we modeled the application as a reactive system all state changes are solely handled by explicit events the url is not a central piece anymore around which the current state is defined it's basically only a byproduct and serves as an entry point telling the system basically dear reactive system please go into this state if you can and if the event is handled not handled in this state the event is simply ignored also since everything is event based it doesn't matter where the events are coming from this means the server-side state changes are a no-brainer and it's basically as simple as forwarding the corresponding event to the system and letting it decide on how to handle it and what state change might occur so we have seen that when we tweet the writer example as a reactive system the problems are going away because we are using a different way to model the system and this basically concludes the talk on the topic of developing reactive systems with amberjs so let's do a final recap so in the beginning we argued that the complexity of front-end applications is inherent because we are dealing with reactive systems we also showed that the state charts are a way to describe such systems in other industries like embedded systems or at nasa they use data charts all the time it seems that we are the only ones who build reactive systems but don't model them as such now if this box dock has picked your interest your next question might be where to go from here so we highly recommend reading through the paper on the reactive systems um you won't be you won't be surprised anymore of how familiar the concepts stated in there are to us front-end developers also the stage paper goes in a much greater detail of the overview and the formalism and characteristics of the state charts and he explains it in a very approachable way um even just using this datejust as a tool to think about your system is already helpful and once we got hooked here we certainly can't imagine engineering apps without them anymore if you want to know more how to use stages within your amber application um go check out the emberstagecharts.com home page which is basically the documentation for the add-on with um with sneak preview we've said in the beginning so basically this add-on allows you to use your visual stature configuration in code so you can use that described behavior um on amazon.com there's a long tutorial and the introduction of how um yeah state charts can be used um within amber applications so we presented our thinking for this paradigm for the first time in such a way to a bigger amber audience this is exciting and we're looking forward to the discussion um i want to close with this final statement if you only take one thing away from this presentation it should be this you're building a reactive system you can ignore that fact but we can tell you from our experience that if you embrace it you will have a much easier time building complex systems awesome thank you so much for this awesome talk has been really insightful as well uh to listen about like uh first of all your rationale and your research about like stage shots but also about lucky work in this regard and i already have like one question um how has the feedback been so far embassadors i haven't used it before so i'm kind of like also curious how uh kind of like community feedback husband um yeah so we have a channel on ember discord um what was kind of surprising to be honest was that it's in the top 10 most downloaded add-ons um the so people seem to be using it um there's an active mrs daycharts channel where more and more people um are talking or collaborating on questions regarding stage arts right um the add-on is pretty old it's already three years old i think um because that's when we started actually using the paradigm in mr.js applications um so yeah people tend to use it and the feedback has been quite positive especially also with our clients so um we've been building apps since three years with a paradigm and basically all the clients that we consult for that we have introduced introduce the paradigm to are like oh my god this solves most of our problems um and this is what what clayman summarized at the end where it's like yeah we can act like we're not building a reactive system um but we actually are so we should actually model it as such right um and it really solves a lot of issues so from from my personal experience um i got from a situation where people were asking me to build stuff although i have a lot of experience building stuff and people approached me and asked me yeah i need to build this and that i need to build a super collaborative text editor or something like that um and before finding this concept i was like yeah um this could get hairy and nowadays it's really like yeah give me the most complex stuff that you can think about it's no issue at all to model that and um that's mostly what we hear from other people as well but also these initially the feedback is mostly this okay this is super complicated um this is also for the tutorial on the msda chats um webpage for example where we are building up uh an async button component and at the end if you look at the configuration that we create um it looks pretty hairy to be honest right um but as clemens pointed out this isn't because it's overly complicated this is simply because the thing that you're building is actually pretty complicated and we just may and and stages just make this complexity um uh explicit and the rest the rest of the coding experience with embargoes gets very very straightforward because literally the only thing that you have to do is forward events to the state chart and the state chart will take care of um figuring out what to do next and then you can actually hook up things like async requests and stuff like that the side effects that the statute should should trigger but overall the entire application development gets very very simple because you spend you spend some time actually thinking about what you're trying to build yeah that makes a lot of sense thinking any more questions in the group uh if there's none then maybe i would have like one more question how can people find out about this blog post that you talked about it goes a little more into detail into state charts if i understood this yeah there's a blog post on the effective ember homepage so effectivemba.com and then there's a blog post called um constructing robust robust applications with with stage ups or something like that and the um you'll be able to find it if you google for it and i can also post it in the chat real quick um yeah and what you're building there's this is important um because you don't have to mod your entire system with state shots right and you don't need to create this super intricate state chat um as the first thing that models your entire system you can also use that paradigm on the component layer um to just build out very complex com components honestly most components are complex enough that they should be driven by a stator in my opinion but yeah i post it in the chat and you can use that paradigm for component [Music] implementations as well so you don't have to go all in and restructure your entire application to make use of that paradigm yeah i just posted it to the channel yeah super thinking any more questions in the group if not then yeah i think it's much again like for this talk um and with this that this is already the end of our meetup thank you so much to all our speakers uh that actually uh gave like amazing talks gave a lot of like insight into how to build up really cool things like with ember um this has been really nice also thank you so much for the support on the uh recording by alex and also um everyone who supported the meetup um and everyone who actually joined and uh uh kind of like came together here today we're really uh happy to see all of you here if you want to keep up to date like with other upcoming events feel free to follow us on twitter as well as we said it's an every now and then meetup so yeah stay tuned and apart from this i would like to wish everyone a nice morning a nice day a nice evening last night and yeah see you around soon [Music] [Applause] [Music] foreign [Music] [Applause] [Music] [Applause] [Music] so [Music] [Music] [Music] hey [Music] [Applause] [Music] me [Music] [Music] [Applause] [Music] [Applause] a [Music] [Music] [Applause] [Music] [Applause] [Music] [Applause] so [Music] [Music] [Music] [Music] you

Channel: Pusher

Views: 375

Rating: 5 out of 5

Keywords: developer language, language code, libraries, help, tips, forum, meet-up, meet up, learn code, coding education, coding hints and tips, lecture, coding lecture, learn about code, learn a developer language, amazon alexa skills, developer conference, node.js, javascript, backend

Id: c-sWTZJ6nlM

Length: 132min 54sec (7974 seconds)

Published: Tue Jul 13 2021