Podcasts about in angular

2023-05-9 Weekly News - Episode 195Watch the video version on YouTube at https://youtube.com/live/7ulzr2lkDRs?feature=share Hosts:  Eric Peterson - Senior Developer at Ortus Solutions Dan Card - Senior Developer at Ortus Solutions Thanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and all your favorite box-es out there. A few ways  to say thanks back to Ortus Solutions: Like and subscribe to our videos on YouTube.  Help ORTUS reach for the Stars - Star and Fork our ReposStar all of your Github Box Dependencies from CommandBox with https://www.forgebox.io/view/commandbox-github  Subscribe to our Podcast on your Podcast Apps and leave us a review Sign up for a free or paid account on CFCasts, which is releasing new content every week BOXLife store: https://www.ortussolutions.com/about-us/shop Buy Ortus's Books 102 ColdBox HMVC Quick Tips and Tricks on GumRoad (http://gum.co/coldbox-tips) Learn Modern ColdFusion (CFML) in 100+ Minutes - Free online https://modern-cfml.ortusbooks.com/ or buy an EBook or Paper copy https://www.ortussolutions.com/learn/books/coldfusion-in-100-minutes  OR — Join us for the 10th Into the Box - In person ONLY!!! Patreon Support (stupendous)We have 40 patreons: https://www.patreon.com/ortussolutions. News and AnnouncementsICYMI - Into the Box - Hackathon added to Happy BoxDuring the first day of Into the Box Conference 2023; on May 18th, we're hosting a Happy Box Party where attendees can connect and network with one another. We're excited to announce that this year, we're introducing a new activity: a Hackathon team-up event! This hackathon is an excellent opportunity for tech enthusiasts to come together, collaborate, share their skills and knowledge, and work on innovative projects that tackle real-world problems. We hope you'll join us for this exciting time! We are currently in the process of finalizing the topics for the hackathon and would love to hear your feedback. We want to make sure that the topics we select are relevant to the interests and expertise of our attendees, so please take a moment to let us know what topics you would be most interested in working on.https://www.ortussolutions.com/blog/what-would-you-like-to-hack-on-at-into-the-box-2023 New Releases and UpdatesColdBox 7 RC ReleasedColdBox 7 RC has been released!  Install it via ForgeBox using `coldbox@be`.  Release at ITB 2023!What's New With ColdBox 7.0.0? Engine Support ColdBox CLI WireBox Updates Transient Request Cache Delegators Property Observers Lazy Properties New `onInjectorMissingDependency` event Population Enhancements (including mass assignment protection) Hierarchical Injectors (for Module Dependencies) Module Config Object Override files App Mode Helpers `redirectBack` included as `back` `DateTimeHelper` component Whoops! Upgrades More data for development REST exception responses JSON Pretty Printing in LogBox Output Exception Pretty Printing in LogBox Output Combine `canXXX` checks with logging using callback functions `event.setRequestTimeout()` - useful for testing https://coldbox.ortusbooks.com/v/7.x/intro/release-history/whats-new-with-7.0.0ColdBox CLI 1.x ReleasedWe are thrilled to announce the release of our new ColdBox CLI tool! This powerful command-line interface is designed to help developers streamline their workflows and simplify their ColdBox development experience. With its intuitive syntax and powerful capabilities, the ColdBox CLI tool allows developers to easily create, test, and deploy ColdBox applications with just a few simple commands. Whether you are a seasoned ColdBox developer or just getting started with this powerful framework, the ColdBox CLI tool is the perfect addition to your toolkit.This tool used to be embedded in the CommandBox core, but it now has a new home (https://github.com/ColdBox/coldbox-cli) and can have it's own life-cycles including LTS support for our ColdBox Framework as well.https://www.ortussolutions.com/blog/coldbox-cli-1x-releasedTestBox CLI 1.x ReleasedWe're excited to unveil our latest **TestBox CLI ** tool! This robust command-line interface is specifically crafted to assist developers in streamlining their workflows and enhancing their TestBox BDD/TDD development process. Boasting an intuitive syntax and potent functionalities, the TestBox CLI tool empowers developers to create, test, and generate reports on their ColdFusion (CFML) applications with ease, using only a handful of commands. Whether you're a seasoned ColdFusion (CFML) developer or a newcomer to this potent framework, the TestBox CLI tool is a valuable asset to add to your toolkit.This tool used to be embedded in the CommandBox core, but it now has a new home (https://github.com/ortus-solutions/testbox-cli) and can have it's own life-cycles.https://www.ortussolutions.com/blog/testbox-cli-1x-releasedWebinar / Meetups and WorkshopsAdobe ColdFusion Workshop: DevOps, CI/CD, and PipelinesWednesday, May 10, 2023Time: 1:00 - 4:30pm ET; 10:00am - 1:30pm PTHost: CarahsoftCost: No FeeMax CPE Credits Available: 4.2 credit hours (1 CPE credit is based on 50 minutes) Field of Study: Information Technology This workshop is ideal for software engineers that are eager to build pipelines to automate their coding projects. Adobe ColdFusion developers are also encouraged to attend. This course will be beneficial for any professional developer who is looking to simplify their application architecture with Adobe ColdFusion and DevOps.https://carahevents.carahsoft.com/Event/Details/358809-cpe Adobe - Road to Fortuna Series: ColdFusion 2023 in Docker on Google Cloud PlatformMay 23, 202310 AM - 11 AM PTDuring GCP centric webinar, Mark Takata will explore how to run a containerized ColdFusion 2023 server on Google Cloud Platform's Kubernetes powered containerization system. He will demonstrate how the powerful new Google Cloud Platform features added to ColdFusion 2023 can help optimize application development, provisioning and delivery. This will be the first time ColdFusion 2023 will be shown running in containers publicly, and the session is designed to showcase the ease of working in this popular method of software delivery.Speaker - Mark Takata - ColdFusion Technical Evangelist, Adobehttps://docker-gcp-coldfusion.meetus.adobeevents.com/ CFCasts Content Updateshttps://www.cfcasts.comRecent Releases 2023 ForgeBox Module of the Week Series - 1 new Video https://cfcasts.com/series/2023-forgebox-modules-of-the-week  2023 VS Code Hint tip and Trick of the Week Series - 1 new Video https://cfcasts.com/series/2023-vs-code-hint-tip-and-trick-of-the-week  Just added 2019 Into the Box Videos Watch sessions from previous ITB years Into the Box 2022 - https://cfcasts.com/series/itb-2022  Into the Box 2021 - https://cfcasts.com/series/into-the-box-2021  Into the Box 2020 - https://cfcasts.com/series/itb-2020  Into the Box 2019 - https://cfcasts.com/series/into-the-box-2019  Coming Soon More ForgeBox and VS Code Podcast snippet videos ColdBox Elixir from Eric Getting Started with Inertia.js from Eric Conferences and TrainingJ on the BeachBringing DevOps, Devs and Data Scientists together around Big DataMay 10-12, 2023 Malaga, Spainhttps://www.jonthebeach.com/ Ortus Profile: https://www.jonthebeach.com/jobs/54/Ortus%20SolutionsVueJS Live MAY 12 & 15, 2023ONLINE + LONDON, UKCODE / CREATE / COMMUNICATE35 SPEAKERS, 10 WORKSHOPS10000+ JOINING ONLINE GLOBALLY300 LUCKIES MEETING IN LONDONhttps://vuejslive.com/ Into the Box 2023 - 10th EditionMay 17-19, 2023 The conference will be held in The Woodlands (Houston), Texas - This year we will continue the tradition of training and offering a pre-conference hands-on training day on May 17th and our live Mariachi Band Party! However, we are back to our Spring schedule and beautiful weather in The Woodlands! Also, this 2023 will mark our 10 year anniversary. So we might have two live bands and much more!!!IN PERSON ONLY https://intothebox.orghttps://itb2023.eventbrite.com/ Can't wait? Watch videos from the last 4 years on CFCasts Into the Box 2022 - https://cfcasts.com/series/itb-2022 Into the Box 2021 - https://cfcasts.com/series/into-the-box-2021  Into the Box 2020 - https://cfcasts.com/series/itb-2020  Into the Box 2019 - https://cfcasts.com/series/into-the-box-2019  VueConf.usNEW ORLEANS, LA • MAY 24-26, 2023Jazz. Code. Vue.Workshop day: May 24Main Conference: May 25-26https://vueconf.us/ CFCamp - Pre-Conference - Ortus has 4 TrainingsJune 21st, 2023Held at the CFCamp venue at the Marriott Hotel Munich Airport in Freising. TestBox: Getting started with BDD-TDD Oh My! Coldbox 7 - from zero to hero Legacy Code Conversion To The Modern World CommandBox Server Deployment for the Modern Age https://www.cfcamp.org/pre-conference.html CFCampJune 22-23rd, 2023Marriott Hotel Munich Airport, FreisingCheck out all the great sessions: https://www.cfcamp.org/sessions.htmlCheck out all the great speakers: https://www.cfcamp.org/cfcamp-conference-2023/speakers.html Register now: https://www.cfcamp.org/THAT ConferenceHowdy. We're a full-stack, tech-obsessed community of fun, code-loving humans who share and learn together.We geek-out in Texas and Wisconsin once a year but we host digital events all the time.WISCONSIN DELLS, WI / JULY 24TH - 27TH, 2022A four-day summer camp for developers passionate about learning all things mobile, web, cloud, and technology.https://that.us/events/wi/2023/Our very own Daniel Garcia is speaking there https://that.us/activities/R3eAGT1NfIlAOJd2afY7Adobe CF Summit WestLas Vegas 2-4th of October.Get your early bird passes now. Session passes @ $99 Professional passes @ $199. Only till May 31st, 2023!Can you spot ME - Gavin - Apparently I'm in 3 of the photos!Call for Speakers is OPENhttps://cfsummit.adobeevents.com/ https://cfsummit.adobeevents.com/speaker-application/More conferencesNeed more conferences, this site has a huge list of conferences for almost any language/community.https://confs.tech/Blogs, Tweets, and Videos of the Week5/5/23 - Tweet - Ben NadelAfter YEARS of trying to make queryExecute() work in Adobe #ColdFusion, I just can't take it anymore. I'm going back to writing my data-gateways using Tags so that I can use the majestic CFQuery tag. I hate having to have all the other cruft; but, until ACF gets "Tag Islands"(Dig into replies for the rationale and a qb mention)https://twitter.com/BenNadel/status/16544396125493248015/6/23 - Blog - Ben Nadel - On Starting A Side-Project: Hotwire vs. AngularFor the last few months, I've been digging into the Hotwire framework. I was initially drawn to Hotwire on its promise of allowing me to build a SPA (Single-Page Application)-like experience using an MPA (Multi-Page Application); and, to do so with less effort. After several months of creating demos and migrating this ColdFusion blog over to using Hotwire, I feel like I have a much better sense of how Turbo Drive, Turbo Streams, and Stimulus work. But, I'm not quite sure that I want to use Hotwire when I start my next side-project.https://www.bennadel.com/blog/4458-on-starting-a-side-project-hotwire-vs-angular.htm5/7/23 - Blog - Ben Nadel - Importing Multiple ColdFusion Custom Tag Directories Using The Same PrefixOne of the nice things you can do with ColdFusion custom tags is import a given directory of custom tags into a "prefix". This allows custom tags to be aliased in the CFML markup; which is a technique that I use quite heavily in my Domain Specific Language (DSL) for generating Emails. One additional feature that I just learned about this prefixing functionality is that you can import multiple directories under the same prefix.As I try to decide if I'm going to start my next project in Hotwire or Angular, one idea that I'm playing with is creating a design system using ColdFusion custom tags. Essentially, I want to be able to take some of the UI (User Interface) encapsulation techniques that I learned in Angular and apply them to Hotwire.In Angular, I have my design system organized into different folders so that I don't end up with a hundred files in one place. Hoping to do the same thing with my ColdFusion design system, I wanted to see if I could aggregate different custom tags under the same prefix.https://www.bennadel.com/blog/4460-importing-multiple-coldfusion-custom-tag-directories-using-the-same-prefix.htm5/7/23 - Blog - Ben Nadel - ColdFusion Custom Tags Can Use Dashed AttributesThis morning, I was playing around with a ColdFusion custom tag that would encapsulate the rendering of a menu. Part of this encapsulation involved propagating attributes from the ColdFusion custom tag onto the underlying Select element. As such, I randomly tried to pass a data- attribute into the ColdFusion custom tag; and, it worked! I didn't know that this was possible with ColdFusion custom tags. Furthermore, it appears to work in both Lucee CFML and Adobe ColdFusion!https://www.bennadel.com/blog/4459-coldfusion-custom-tags-can-use-dashed-attributes.htmBONUS:Ha…the Updates4Devs bot strikes again.Custom Tags -> Personalized TagsDashed-Attribute -> Rushed Characteristics

In Angular apps, remembering user-preferred settings is an excellent way to provide a good experience for the users; you can save data in the user's browser using the localStorage object, which provides methods for working the key-value data.  Today on the show, GDE Angular expert Dany Paredes shares his insights about localStorage, how to learn about this API, and knowledge to build in Angular to save background color preferences.   In this episode… How localStorage works and limitations API examples and use cases Possible performance issues Trusting the localStorage and API mock values Complicated use cases Angular content in Spanish Sponsors Top End Devs Raygun | Click here to get started on your free 14-day trial Coaching | Top End Devs Links ng-content Angular Basics: localStorage Object Keeps Data in Browser Twitter: @danywalls Dany Paredes | Javascript / Web Picks Charles- Quartile Charles- Funnel Hacking LIVE 2022 Charles - Angular Remote Conf Dany – Enjoys comparing NBA players to Angular developers

In Angular apps, remembering user-preferred settings is an excellent way to provide a good experience for the users; you can save data in the user's browser using the localStorage object, which provides methods for working the key-value data.  Today on the show, GDE Angular expert Dany Paredes shares his insights about localStorage, how to learn about this API, and knowledge to build in Angular to save background color preferences.   In this episode… How localStorage works and limitations API examples and use cases Possible performance issues Trusting the localStorage and API mock values Complicated use cases Angular content in Spanish Sponsors Top End Devs Raygun | Click here to get started on your free 14-day trial Coaching | Top End Devs Links ng-content Angular Basics: localStorage Object Keeps Data in Browser Twitter: @danywalls Dany Paredes | Javascript / Web Picks Charles- Quartile Charles- Funnel Hacking LIVE 2022 Charles - Angular Remote Conf Dany – Enjoys comparing NBA players to Angular developers

Panel: Charles Max Wood John Papa Ward Bell Special Guests: Ilya Bodrov & Roman Kutanov In this episode, the Adventures in Angular panel talks with Ilya and Roman. Ilya is a professor, writer, and developer. Roman is a cofounder, and a CEO, of a small startup company. Roman is making an application for small businesses, and he also was a CEO of a Russian startup, too. Check-out today’s episode where the panel talks to the guests about Angular, their startup companies, Test Cafe, among others. Show Topics: 1:20 – Guests’ backgrounds. 2:31 – Chuck: Let’s talk about Angular. In your opinion why is it a good option for startups? 2:55 – Guest: Angular is a very good choice. 3:55 – Guest: If you are not familiar with these concepts or a seasoned developer then it can be difficult and complex to get started. It really depends on what you are trying to build. 4:47 – Chuck: Once you get rolling with it then you run into limitations with it. If you need something simple and fast it’s really nice. 5:08 – Guest: Yes. Trying to find your market niche. Angular is very simple to transfer. Angular has a great community. There are some problems, and we know it. Like the whole mess with versions also... 6:27 – John: Can you elaborate a little? 6:34 – Guest: Yes, if you want to be in the latest technologies...so sometimes you get into a situation when you wan to have some libraries installed and you cannot do that. If you are on one version and this one isn’t supported, then it was a huge mess. 7:43 – Guest adds in more comments. 8:26 – Guest: Currently I have Angular 1. It is too complicated to rewrite. 8:40 – Guest adds comments. 8:57 – John: There would have to be a compelling reason for me to go to Angular 6 at this point. Going from 4 to 5 or 5 to 6 – the one feature – boy that is so amazing. To have it to update your app, and update your code then that’s awesome. If you didn’t know that a command changed then you were in trouble. I agree version control has always been a challenge. 10:20 – Guest: What I like about Angular is the community – it drives it in the right direction. They try to make it more productive and that’s what I like. 10:43 – Chuck: What is it like to run a startup? 10:56 – Guest: I started to write the application. What you see is what you get. I use Angular 1. JavaScript is a heavier language. 14:54 – Guest adds comments. 16:02 – Panelist: What kind of server are you using for your startup? 16:19 – Guest: I have Angular 1 as a backhand. The main application right now is... 17:11 – Panelist: What has the experience been like for people? 17:26 – Guest: Yes... 17:32 – Panelist: What were the benefits of using Angular? 17:40 – Guest: Angular was very helpful. The performance is much better. Important for startups is to know how to write functionality. 18:53 – Panelist: What forms were you using? 19:01 – Guest: Template driven. In Angular 1, I created “what you see is what you get.” 19:52 – Panelist: I am torn about forms. The Reactive side but you move a lot of code that doesn’t feel all that intuitive to me. There are pros and cons of each, but it’s not exactly where I want it to be. I would love to mix the 2 together. Have you dealt with validation in the forms? 21:04 – Digital Ocean’s Advertisement. 21:41 – Guest: I have an editor. I send it to the client. Each input is having some sort of validation. 23:17 – Panelist: How do you make them look good? Yeah, I can do it but how does it not look generic? Do you have a layout? 23:53 – Guest: I throw it into the screen – I try to keep it simple. 25:04 – Panelist: That makes sense. I didn’t know if there was a crossover of complexity. I want a balance between... 25:38 – Panelist: Reactive or Template driven? 25:45 – Guest makes comments. You want to have some custom checking. 26:13 – Panelist: Why was it hard? 26:21 – Guest: Not sure...I experimented a lot. 27:27 – Panelist: I gave up on Reactive. One of the killers for me was the nested components. It seemed to fall apart in my hands. It was extremely difficult. The outer form lost contact to what was going on. That was one of the biggest decisions to walk away from Reactive all together. 28:25 – Guest: Now I remember why I dropped templates. 28:44 – Panelist: Not true, but it’s doable! It’s also easy! You have to know what’s going on. Let’s change the story on this – I don’t want to hijack the podcast. 30:55 – Panelist: It makes your ears stand up. John’s objection was that he was putting a lot of stuff into HTML. 32:43 – Panelist: Every time I see some try to decorate the HTLM – no you don’t have to do that. The rules aren’t there. There are exceptions, of course, but real validation is not screen validation. Interestingly, we have written one for this application. It belongs to Marcel. This isn’t Breeze specific – maybe we an get people to working on it. For sure, even if you didn’t have this framework, you can create one on your own. It turns out that it has more models than you think it does. 34:55 – Panelist: Aside from forms, what mattered in your app? 35:22 – Guest answers the question. 36:01 – Panelist: Lazy Loading. In some apps lazy loading doesn’t make sense in all areas. You don’t always have to use. 36:53 – Guest: Yes, when you work for your employer you sometimes have more time available. When you have a startup it’s a race. Your startup doesn’t have any money. 37:24 – Panelist: You had money? 37:33 – Guest: You have to try new things and makes things right. When users really start really using your application. You can fix everything and make the perfect app or you can learn new things about your users. What problems do that have? 38:50 – Panelist: Question asked. 39:40 – Guest answers question.  40:38 – Protractor. 41:51 – Problems that you/we ran into. 42:21 – Panelist: “We” are using Test Cafe. 42:58 – Cypress. 44:10 – You do not need web driver and... 44:29 – Test Cafe is free. 44:39 – I would pay ten’s of dollars to use a piece of software. It’s a budget buster. 45:15 – Sounds like you guys have a great product there. 45:24 – Thanks for having us. 45:30 – Chuck: Let’s go to picks! 45:39 – Code Badges! 46:13 – Picks! Links: Microsoft’s Azure JavaScript Ruby Angular Test Cafe Cypress Ilya’s GitHub Ilya’s SitePoint Ilya’s Twitter Roman’s Crunchbase Roman’s LinkedIn Roman’s Twitter Sponsors: Angular Boot Camp Digital Ocean Get a Coder Job course Picks: Charles Microsoft Ignite Microsoft Connect Follow me on Twitter! Apple Event John Pipelines – Azure VS Code Ward Test Cafe Ilya Framework Event Roman Michael Seibel’s Building Product MLcourse.AI – October 1st next session starts – it’s free

Panel: Charles Max Wood John Papa Ward Bell Special Guests: Ilya Bodrov & Roman Kutanov In this episode, the Adventures in Angular panel talks with Ilya and Roman. Ilya is a professor, writer, and developer. Roman is a cofounder, and a CEO, of a small startup company. Roman is making an application for small businesses, and he also was a CEO of a Russian startup, too. Check-out today’s episode where the panel talks to the guests about Angular, their startup companies, Test Cafe, among others. Show Topics: 1:20 – Guests’ backgrounds. 2:31 – Chuck: Let’s talk about Angular. In your opinion why is it a good option for startups? 2:55 – Guest: Angular is a very good choice. 3:55 – Guest: If you are not familiar with these concepts or a seasoned developer then it can be difficult and complex to get started. It really depends on what you are trying to build. 4:47 – Chuck: Once you get rolling with it then you run into limitations with it. If you need something simple and fast it’s really nice. 5:08 – Guest: Yes. Trying to find your market niche. Angular is very simple to transfer. Angular has a great community. There are some problems, and we know it. Like the whole mess with versions also... 6:27 – John: Can you elaborate a little? 6:34 – Guest: Yes, if you want to be in the latest technologies...so sometimes you get into a situation when you wan to have some libraries installed and you cannot do that. If you are on one version and this one isn’t supported, then it was a huge mess. 7:43 – Guest adds in more comments. 8:26 – Guest: Currently I have Angular 1. It is too complicated to rewrite. 8:40 – Guest adds comments. 8:57 – John: There would have to be a compelling reason for me to go to Angular 6 at this point. Going from 4 to 5 or 5 to 6 – the one feature – boy that is so amazing. To have it to update your app, and update your code then that’s awesome. If you didn’t know that a command changed then you were in trouble. I agree version control has always been a challenge. 10:20 – Guest: What I like about Angular is the community – it drives it in the right direction. They try to make it more productive and that’s what I like. 10:43 – Chuck: What is it like to run a startup? 10:56 – Guest: I started to write the application. What you see is what you get. I use Angular 1. JavaScript is a heavier language. 14:54 – Guest adds comments. 16:02 – Panelist: What kind of server are you using for your startup? 16:19 – Guest: I have Angular 1 as a backhand. The main application right now is... 17:11 – Panelist: What has the experience been like for people? 17:26 – Guest: Yes... 17:32 – Panelist: What were the benefits of using Angular? 17:40 – Guest: Angular was very helpful. The performance is much better. Important for startups is to know how to write functionality. 18:53 – Panelist: What forms were you using? 19:01 – Guest: Template driven. In Angular 1, I created “what you see is what you get.” 19:52 – Panelist: I am torn about forms. The Reactive side but you move a lot of code that doesn’t feel all that intuitive to me. There are pros and cons of each, but it’s not exactly where I want it to be. I would love to mix the 2 together. Have you dealt with validation in the forms? 21:04 – Digital Ocean’s Advertisement. 21:41 – Guest: I have an editor. I send it to the client. Each input is having some sort of validation. 23:17 – Panelist: How do you make them look good? Yeah, I can do it but how does it not look generic? Do you have a layout? 23:53 – Guest: I throw it into the screen – I try to keep it simple. 25:04 – Panelist: That makes sense. I didn’t know if there was a crossover of complexity. I want a balance between... 25:38 – Panelist: Reactive or Template driven? 25:45 – Guest makes comments. You want to have some custom checking. 26:13 – Panelist: Why was it hard? 26:21 – Guest: Not sure...I experimented a lot. 27:27 – Panelist: I gave up on Reactive. One of the killers for me was the nested components. It seemed to fall apart in my hands. It was extremely difficult. The outer form lost contact to what was going on. That was one of the biggest decisions to walk away from Reactive all together. 28:25 – Guest: Now I remember why I dropped templates. 28:44 – Panelist: Not true, but it’s doable! It’s also easy! You have to know what’s going on. Let’s change the story on this – I don’t want to hijack the podcast. 30:55 – Panelist: It makes your ears stand up. John’s objection was that he was putting a lot of stuff into HTML. 32:43 – Panelist: Every time I see some try to decorate the HTLM – no you don’t have to do that. The rules aren’t there. There are exceptions, of course, but real validation is not screen validation. Interestingly, we have written one for this application. It belongs to Marcel. This isn’t Breeze specific – maybe we an get people to working on it. For sure, even if you didn’t have this framework, you can create one on your own. It turns out that it has more models than you think it does. 34:55 – Panelist: Aside from forms, what mattered in your app? 35:22 – Guest answers the question. 36:01 – Panelist: Lazy Loading. In some apps lazy loading doesn’t make sense in all areas. You don’t always have to use. 36:53 – Guest: Yes, when you work for your employer you sometimes have more time available. When you have a startup it’s a race. Your startup doesn’t have any money. 37:24 – Panelist: You had money? 37:33 – Guest: You have to try new things and makes things right. When users really start really using your application. You can fix everything and make the perfect app or you can learn new things about your users. What problems do that have? 38:50 – Panelist: Question asked. 39:40 – Guest answers question.  40:38 – Protractor. 41:51 – Problems that you/we ran into. 42:21 – Panelist: “We” are using Test Cafe. 42:58 – Cypress. 44:10 – You do not need web driver and... 44:29 – Test Cafe is free. 44:39 – I would pay ten’s of dollars to use a piece of software. It’s a budget buster. 45:15 – Sounds like you guys have a great product there. 45:24 – Thanks for having us. 45:30 – Chuck: Let’s go to picks! 45:39 – Code Badges! 46:13 – Picks! Links: Microsoft’s Azure JavaScript Ruby Angular Test Cafe Cypress Ilya’s GitHub Ilya’s SitePoint Ilya’s Twitter Roman’s Crunchbase Roman’s LinkedIn Roman’s Twitter Sponsors: Angular Boot Camp Digital Ocean Get a Coder Job course Picks: Charles Microsoft Ignite Microsoft Connect Follow me on Twitter! Apple Event John Pipelines – Azure VS Code Ward Test Cafe Ilya Framework Event Roman Michael Seibel’s Building Product MLcourse.AI – October 1st next session starts – it’s free

Panel: Charles Max Wood John Papa Ward Bell Special Guests: Ilya Bodrov & Roman Kutanov In this episode, the Adventures in Angular panel talks with Ilya and Roman. Ilya is a professor, writer, and developer. Roman is a cofounder, and a CEO, of a small startup company. Roman is making an application for small businesses, and he also was a CEO of a Russian startup, too. Check-out today’s episode where the panel talks to the guests about Angular, their startup companies, Test Cafe, among others. Show Topics: 1:20 – Guests’ backgrounds. 2:31 – Chuck: Let’s talk about Angular. In your opinion why is it a good option for startups? 2:55 – Guest: Angular is a very good choice. 3:55 – Guest: If you are not familiar with these concepts or a seasoned developer then it can be difficult and complex to get started. It really depends on what you are trying to build. 4:47 – Chuck: Once you get rolling with it then you run into limitations with it. If you need something simple and fast it’s really nice. 5:08 – Guest: Yes. Trying to find your market niche. Angular is very simple to transfer. Angular has a great community. There are some problems, and we know it. Like the whole mess with versions also... 6:27 – John: Can you elaborate a little? 6:34 – Guest: Yes, if you want to be in the latest technologies...so sometimes you get into a situation when you wan to have some libraries installed and you cannot do that. If you are on one version and this one isn’t supported, then it was a huge mess. 7:43 – Guest adds in more comments. 8:26 – Guest: Currently I have Angular 1. It is too complicated to rewrite. 8:40 – Guest adds comments. 8:57 – John: There would have to be a compelling reason for me to go to Angular 6 at this point. Going from 4 to 5 or 5 to 6 – the one feature – boy that is so amazing. To have it to update your app, and update your code then that’s awesome. If you didn’t know that a command changed then you were in trouble. I agree version control has always been a challenge. 10:20 – Guest: What I like about Angular is the community – it drives it in the right direction. They try to make it more productive and that’s what I like. 10:43 – Chuck: What is it like to run a startup? 10:56 – Guest: I started to write the application. What you see is what you get. I use Angular 1. JavaScript is a heavier language. 14:54 – Guest adds comments. 16:02 – Panelist: What kind of server are you using for your startup? 16:19 – Guest: I have Angular 1 as a backhand. The main application right now is... 17:11 – Panelist: What has the experience been like for people? 17:26 – Guest: Yes... 17:32 – Panelist: What were the benefits of using Angular? 17:40 – Guest: Angular was very helpful. The performance is much better. Important for startups is to know how to write functionality. 18:53 – Panelist: What forms were you using? 19:01 – Guest: Template driven. In Angular 1, I created “what you see is what you get.” 19:52 – Panelist: I am torn about forms. The Reactive side but you move a lot of code that doesn’t feel all that intuitive to me. There are pros and cons of each, but it’s not exactly where I want it to be. I would love to mix the 2 together. Have you dealt with validation in the forms? 21:04 – Digital Ocean’s Advertisement. 21:41 – Guest: I have an editor. I send it to the client. Each input is having some sort of validation. 23:17 – Panelist: How do you make them look good? Yeah, I can do it but how does it not look generic? Do you have a layout? 23:53 – Guest: I throw it into the screen – I try to keep it simple. 25:04 – Panelist: That makes sense. I didn’t know if there was a crossover of complexity. I want a balance between... 25:38 – Panelist: Reactive or Template driven? 25:45 – Guest makes comments. You want to have some custom checking. 26:13 – Panelist: Why was it hard? 26:21 – Guest: Not sure...I experimented a lot. 27:27 – Panelist: I gave up on Reactive. One of the killers for me was the nested components. It seemed to fall apart in my hands. It was extremely difficult. The outer form lost contact to what was going on. That was one of the biggest decisions to walk away from Reactive all together. 28:25 – Guest: Now I remember why I dropped templates. 28:44 – Panelist: Not true, but it’s doable! It’s also easy! You have to know what’s going on. Let’s change the story on this – I don’t want to hijack the podcast. 30:55 – Panelist: It makes your ears stand up. John’s objection was that he was putting a lot of stuff into HTML. 32:43 – Panelist: Every time I see some try to decorate the HTLM – no you don’t have to do that. The rules aren’t there. There are exceptions, of course, but real validation is not screen validation. Interestingly, we have written one for this application. It belongs to Marcel. This isn’t Breeze specific – maybe we an get people to working on it. For sure, even if you didn’t have this framework, you can create one on your own. It turns out that it has more models than you think it does. 34:55 – Panelist: Aside from forms, what mattered in your app? 35:22 – Guest answers the question. 36:01 – Panelist: Lazy Loading. In some apps lazy loading doesn’t make sense in all areas. You don’t always have to use. 36:53 – Guest: Yes, when you work for your employer you sometimes have more time available. When you have a startup it’s a race. Your startup doesn’t have any money. 37:24 – Panelist: You had money? 37:33 – Guest: You have to try new things and makes things right. When users really start really using your application. You can fix everything and make the perfect app or you can learn new things about your users. What problems do that have? 38:50 – Panelist: Question asked. 39:40 – Guest answers question.  40:38 – Protractor. 41:51 – Problems that you/we ran into. 42:21 – Panelist: “We” are using Test Cafe. 42:58 – Cypress. 44:10 – You do not need web driver and... 44:29 – Test Cafe is free. 44:39 – I would pay ten’s of dollars to use a piece of software. It’s a budget buster. 45:15 – Sounds like you guys have a great product there. 45:24 – Thanks for having us. 45:30 – Chuck: Let’s go to picks! 45:39 – Code Badges! 46:13 – Picks! Links: Microsoft’s Azure JavaScript Ruby Angular Test Cafe Cypress Ilya’s GitHub Ilya’s SitePoint Ilya’s Twitter Roman’s Crunchbase Roman’s LinkedIn Roman’s Twitter Sponsors: Angular Boot Camp Digital Ocean Get a Coder Job course Picks: Charles Microsoft Ignite Microsoft Connect Follow me on Twitter! Apple Event John Pipelines – Azure VS Code Ward Test Cafe Ilya Framework Event Roman Michael Seibel’s Building Product MLcourse.AI – October 1st next session starts – it’s free

In dieser Happy Angular Podcast Folge schauen wir uns Direktiven an. Eine Direktive sind Befehle, die das Aussehen des Templates anpassen. Angewendet kann eine Direktive auf ein HTML Element oder einer Komponente. In Angular gibt es drei verschiedene Arten von Direktiven: Attribute Direktive, strukturelle Direktive und eine Komponente. Neben den Standard-Angular Direktiven können wir auch eigene Direktiven schreiben.

In the last episode, we spoke a lot about the "why?" behind microstates. This time we wanted to cover how ideas in Microstates map to different patterns used to build JavaScript applications using frameworks like React, Ember, Vue and Angular. We discussed what you need to know about Microstates if you prefer component state architecture or global store architecture like Redux, as well as how setState in React can be refactored to use Microstates. We closed off with the comments about the trade offs that component heavy frameworks make by overemphasizing the view layer at expense of other aspects of the MVC pattern. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Upcoming Conference Talks: Manhattan.js - August 8th (Taras) ReactJS Austin August 6th (Charles) Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #107. My name is Charles Lowell and we are going to be following up with our Episode 106 with the exciting conclusion of 'Microstates, the Podcast.' With me today to wrap this subject up, at least for the near term, obviously we're going to be talking about it a lot in the days and months to come, are David and Taras, also co-developers here at Frontside. Hello guys. TARAS: Hello, hello. DAVID: Hi everyone. CHARLES: Before we get into that, we'll just make a few quick announcements. First off is here at Frontside, we are going to be having some availability at the end of August. If you or anyone on your team is looking to level up in the area of testing, especially testing single page applications, acceptance testing single page applications or if you need React or general JavaScript consulting, please get in touch. We would love to work with you and love to do some of the great things together. Second, we finally released this and this is germane to the topic at hand. We released a major version of microstates this week that's based on a new and simpler architecture. That's really exciting. It doesn't really change the content of the conversation because the API hasn't changed that much. It just means that the library, which was already very small is even smaller. I think we shaved almost 40% of the size off and it's just much simpler and it's much more harmonious with the underlying JavaScript runtime. It's even more just simple JavaScript objects. Unless there's any other news that you want to cover, we'll jump right into it. TARAS: All right. Let's do it then. Let's do microstates. CHARLES: I Love to talk about microstates. This is obviously the second podcast that we're doing on microstates, just because we ended up, I think it was two weeks ago and we'd been speaking for almost an hour and really, we're just laying out the problems that microstates solve -- the problems of state management and why you often run up against complexity when you have a single state management tool that doesn't account for a bunch of different use cases. We got into microstates a little bit but we left it as kind of a cliffhanger. We talked about transactionality and laziness and immutability, ease of composition, simplicity of API, performance, memory footprint, things like this. Those were all the problems and then we're like, "Yeah, microstates. It's awesome." We're going to talk a little bit more about actual microstates proper and what is involved like the adjustments in mindset that you need to make or don't need to make when adopting a tool like microstates. TARAS: Actually, it's been really interesting for me because I just gave a talk at Toronto JS on microstates and it was pretty cool to see. There was a panel at the end. I think the people that are representing just using component state as a way of architect implication. It was managing state and application and it's representing redux. It's really interesting to see, first of all, like how curious people were. Most of questions were directed to the discussion around microstate, simply because it is a new tool but it was also just interesting to see how curious people who really loves redux, he was like, "I really love redux but I really like that fact that you guys have types," so I was like, "Oh, that's cool." Even though you really liked your solution, you actually found something in microstates interesting but at the same time, I think he was kind of missing that what aspects of Microstates overlap with redux. I think one of the things that we can do today is talk about what microstates has and what API does microstates provides and how similar they are to what people already know. I think that's one of the things that I was thinking about this conversation is that there are some things around microstates API like how to use microstates but the architectural concepts that power a microstates, they are already part of the development process and development architectures for most people that building single page applications. I think we can do is try to map these ideas not what people really know and patterns that they use to ideas in microstates, just to show how close we actually are. I think that's a good way for us to go. CHARLES: I guess we can start with, maybe one particular mode of managing state and then, how that maps to uses with microstates. TARAS: Let's start with components state because that was kind of our starting point. One of the original starting points for microstates because so much of our work was in Ember and component state is where most of Ember development happens. I think that's a good place to start. If you're someone who uses components state, if you're using Ember or Vue without something that is redux-ish which is pretty common these days, if you use components state, then one of the features of -- CHARLES: And also, if you're using React, right? Ember, Vue and React pretty much are all the same in this regard. TARAS: Yeah. Well, Ember and Vue are a little bit different in that behalf. Their particular pattern is you have data coming into the component, then you're doing some work with the data so that in Ember and Vue, you might use computed properties to derive state on that and then you might pass that state further down into other components. In React, you would do something a little bit different because there is no memorized computed properties by default, so you, a lot of times, write your computations that you pass into other computers that are written as expressions in JSX. If you're using this pattern, then one of the challenges around using this pattern is the process of lifting state becomes quite complicated. Because if you have like a bunch of state that lives in the component, it's attached to your derivation of state and the properties that you can invoke are attached to a component object. In React world, it's called lifting state. In Ember world, it'd be essential refactoring it into the parent component and passing that state in. in microstates, you're essentially moving this state into the microstate and now, what you have is this object that instead of having the state live on the component, the state now lives on the microstate object and in all frameworks, when you do that in microstates, you can use the getters to get the memorized computed properties behavior on the microstate. If you use your computed properties, computed properties are available for you on the microstate. You can do it the same way. CHARLES: It's kind of like a wrap up of that idea, not a wrap up but a summary of that idea is that the microstate essentially is a substitute for your component properties. If you're working with a component, a component has state associated with it, so you're setting properties on a component and then using the computed properties of that component. Microstates is you have all those benefits where you can set properties directly. You can define methods that like set properties as part of a transaction and you can then have simple JavaScript getters, which are just like computed properties except there's no enumeration of dependent keys. It's just, that's all they do for you. TARAS: Then the next question that arises is like, "Do I make like one huge microstate or a bunch of smaller microstates?" I think the question is really depends on the role of your component and what's nice thing about microstate is in microstates, there's two things that are kind of cool. One is when you represent your status in microstate, it makes it very easy. If you need to lift that state from the component up into the parent, you can lift that type. You can take that type and you can compose that type into the parent's microstate, if you have to and in that case, you would pass this new object that's created from that type. You'd pass the state for that component to the component that would otherwise have its own state. Essentially now, the parent has the state that would otherwise be in a child component and now, the parent is passing a state from the parent to the child. There's two kind of benefits to that. One is it gives a parent a way to control the state of the child and it also gives you a really easy way to serialize and deserialize state. You start off with having ability to serialize state for a particular component and all of his children, now you can represent that serialized state as part of the components state, so you have an easy way to restore the state of the component tree at the parent component. CHARLES: Right and that's possible because a microstate is really just encapsulating a value within a type but the value is just a simple serializable plain old JavaScript object, right? TARAS: Yeah. CHARLES: I'm just not trying to say like this is the feature that microstate provide, so when you're creating a microstate, you just pass it a POJO and it off to the races with that POJO and you can access that POJO at any single point. TARAS: Yeah. This is part of the architecture that I think are helpful for people that are using components. Is there anything else for people who are using components state that we think would be helpful? CHARLES: I think we're just realizing that you get the benefit of the laziness and immutability and the transactionality and all kind of things that we talked about last time but actually, the mental model is very similar. I think the thing to realize is that if that's the way that you used to working with state, the bridge is not too far. It's actually quite a short one. TARAS: Yeah, that's good. CHARLES: It feels very natural. It's not a huge mental shift. It's just more about a very small mental shift, a very small shift in mechanics for a very large payoff. DAVID: For instance, say you're in an Ember application using component state, what I'm used to is you're going to be passing actions around between components. Whenever you're trading that out for microstates, is it more that these actions are just bundle in with the microstate as the transition? TARAS: Yeah. One nice thing with the microstate, because the transitions that you can perform on any data type are intrinsic to the actual data type, the part of the data type, when you instantiate a microstate, you get these transitions for free. When you pass the object into a component, you can now invoke transitions on that object, that are part of that object's type. It's hard to imagine how awesome that really is because the closest pattern that you would see for that would be like, for example, if you're using Ember, you have Ember object or Ember model that you pass into a component and then, you can work a transition and because it goes through the Ember data store, your component is going to update. With microstates, there's no observation of any kind but what you're doing is when you are invoking the transition, transitions going up to the top of the root and gives you the next microstate, which updates your component tree. You get that functionality of 'data-down, actions-up'' built into the entire system of the microstates and all of that is hooked into these transitions that you can invoke on the objects that you pass into your components. CHARLES: Right, maybe David and Taras, you all could provide a concrete example of what that looks like. Because I think it is something that when I was giving talks on microstates at Ember meetups, one of the first things I like to show is you've got all these actions that you're writing either on your router or your controller but they're really actions manipulating the same type of data. It really comes down to like you're pushing and popping things off of arrays, you're toggling Booleans, you're incrementing counters, you're setting this property on this object. These are actions that we're writing and in the kind of microstates world, that's boilerplate. Because the transitions are intrinsic to the data type of the microstate that you're working with, maybe we could provide an example, like what's an action that you describe that you would pass around. TARAS: I think an easier one would be like if you have a model for example, you're composing a model into your application state or you're compose a model into your components state, so you have this model type that gets instantiated and you pass it into component that represents a model. Off that model, you might have open status like is it open or not that gets consumed by the model component, to know whether the model should be visible. Then along with that is model is open state, there is a toggle transition that you can find inside your component that is going to automatically flip the visibility of open. What will happen when you bind that transition to some kind of action handler that you invoke inside your component, when you invoke that action, it will then trigger transition at the top of that microstates and then, it will create the next state, push it through which will cause your model to change the visibility. David, that does answer the question? DAVID: Yeah, it does and that's actually the example that I have come up with whenever asked. A very simple sort of Boolean toggle. CHARLES: In a couple of my earlier demos, I should dust off that talk that I gave to the Austin Ember meetup where I was able to create an input with a dropdown menu with basically, some pretty advanced mouse behavior, all without having any component state or like storing it all in microstates and a lot of pushback was, "Aren't you putting logic in the template?" and the answer is, "Absolutely not." The logic is in the models but what I'm doing is I'm composing the actions that operate on those models inside the templates but at the template level, the action is data. If you're thinking about, we always want to have, we always want to lift state and then push that state down to the application, what this is really saying is that the actions are part of the data. It is implicit to the value that you've got. TARAS: I think that's really powerful because we do think about actions as being something that you can invoke. Like with closures, it's an action that you can invoke but considering that operation, that piece of data that invokes a transition in microstates and is derived from the type of the data, I think it's a cool concept. That's probably, one of the things that is kind of new for microstates but how you use it in your application should feel pretty much the same as you would if you were creating action handlers on your components. CHARLES: Yeah, just like kind of bundled action handlers for free. TARAS: Right. CHARLES: Maybe the way that you wrap up on this one when talking about kind of what microstates has to offer for the Ember developer, the Vue developer is really, I would say someone who's used to working with like MobX. Would be another good example is when I first started using Ember back in 2012, Ember Object solved a whole lot of issues in a really profound fundamental way and I really, really was drawn to that as the best API to be working with state. What kind of became apparent was perhaps not the best implementation. This is not like bag on Ember Object. I think it was actually amazing technology for seven years ago when most of it was written and probably, even came from before like SproutCore. It's almost 10 years old, which is incredible but it's still under heavy use in 2018 and it speaks well of how well it was constructed. I actually don't have much of a problem with Ember Object API. I just think that the way in which it's implemented that API means that there are some problems that require a different paradigm, so very much I kind of see microstates as heavily inspired by those types of APIs but with, I want to say a modern implementation but an implementation that is designed to solve the problems that have come to light over the last five years of developing single page JavaScript application. TARAS: I want to add that, when you describe with Ember Object, it exists in every framework that uses immutability. In MobX, the observation introduces the necessity to wait for a bunch of things to resolve. In Angular zones, I saw a similar purpose to ensure that if there are kind of cascading or streams or all of that stuff gets settled in into kind of restful state before you can start to assert on what's going on and with Vue, their computed properties has something similar. I think because of the complexity of having to track lots of objects and then recomputing things based on the result, that complexity in microstates is simplified by the fact that you describe you transitions. When you write them, you describe exactly what changes, so we don't need to wait for things to settle down. When you invoke a transition, that transition is explicit and based on the path of where that transition is invoked, we know exactly what needs to change, so we need to only perform one operation to compute the next state. There is no other things that we need to wait. There's no other side effects that we need to resolve before we know what the final status. I think that simplicity can be applied to all the frameworks that are using immutable APIs and derived computations from those immutable APIs. CHARLES: Uhm-mm [affirmative]. TARAS: Should we jump into talking about what microstates has to offer for people familiar with redux? CHARLES: Yeah, okay. Let's jump right into it. For folks who are familiar with immutable APIs like Ember, like Vue, like other ecosystem using MobX, a shift to microstates might feel like what you can expect. What about people who are just using often React-land and they're just using like set state. TARAS: Set state is a little bit tricky because it does get complicated over time and then you get this kind of funky things going on after a while where you start seeing things like, "I'm going to set state on this component and then once the change happens, I'm going to change some states some other state," so this kind of cascading state changes. The other part that I find particularly more challenging in set state world than it is in, I think in regular components state, like what you have with Vue and Ember. I feel like the way that the transitions, the state change handlers become part of the component, I find that part particularly kind of fragile. When you start doing refactoring, when you need to lift up state, it's like -- CHARLES: What's an example of this? TARAS: When you start off and your component owned old state and now, you need to have that state being controlled by the parent, we get into a situation where like, "What am I going to do? Am I going to do something with props as they're coming into the component or I should probably just flip that state from the child to the parent?" and now, you're refactoring the internals of a component to lift up that state so you can then combined those operation with the parent's state transitions. But then, you have this kind of added complexity of the fact that you're working with immutable data in that place. You've got these three things going on: you're refactoring your child component, you are moving these things into the parent components, you modify a parent component and now, you're also managing the complexity of forming immutable objects. I think the fact that people make it work is kind of a testament to human resilience. The people are able to solve such challenging problems and this is not a super hard one but when a component is complex enough and when stakes are high enough, these changes can become fragile. This is what I think microstates simplifies is that by taking care of the model, it makes components much simpler and makes it possible for you to just render a lot of components that are functional components without their own state. CHARLES: It actually reminds me and like I said, we're talking about what it's like to use them, not so much the implementation but that's the exact same sentiment that the author expressed in his book that was very helpful in writing microstates, which is Brian Marick. He has this book called 'Lenses for Mere Mortals' and he's talking about the practical use cases of using lenses, which microstates leans very heavily on. What he says right in the introduction is it gives you by abstracting the location and compose it the way in which your data structures are composed, it makes them very refactorable. You can say, "I want to change where the state lives. I want to change the structure of this object and I want to move it somewhere else," and it's sounds weird to say this, because the structure of the object is not coupled to the structure of the object, it means that it's very malleable, so you can move and you can say, "You know what? I don't want this address to be embedded in this person. I want this address to be inside this address book and then my person has an address book entry." Being able to make those refactors make those changes is very easy because your method of accessing the data is abstracted. It's something that applies beyond even user interface as a component state but it's something that this is a problem that's very salient when you are authoring complex UIs and compose components. It's something that you can benefit very greatly from. DAVID: Taras, you were telling us earlier about a friend of yours who is learning React for the first time over the past few months and he's mainly been using set state as you would just starting out in this world. You said that he didn't really get why you might have to go and learn some other way to manage your state and I think Charles said it, whenever your application starts to get more complex and you've got a lot of different moving parts, that's really where microstates will come out and shine for you. TARAS: Yeah. My friend kind of feel bad because he's spent the last three months learning how to work with React and how to use set state, "And now, you're telling me, I need to learn something else? Like I'm going to start from scratch?" I kind of reassured him that especially when you're a beginner, when you're learning, you learn how to address very specific challenges but you don't know how complicated these things can get when your UI gets really intricate. In those intricate scenarios is when you have to leverage your experience and you'll be able to solve these problems but if you're learning, you encounter these challenges head on and your tool does not really, like set state. Although it can be used to build really complex UIs very effectively but the complexity that over time increases as you start to manage the state, increases much more later on than does early in the beginning. Basically, with microstates, even if you have some basic proficiency with set state, when you start working with microstate, the things that you can do with microstates, you will be able to do more sophisticated things easier when you need to use them than you might realize when you start. Because microstates API is so consistent, there are a very few concepts to actually learn and they cover a broader range of use cases so when you actually starts using it, you'll encounter these challenges. What you already know it will just work for you and always just continue to work for you. That was part of kind of fundamental design on what Charles and I have spent, a lot of time putting into place from a point when we started two years ago. CHARLES: I think, and you touched on this and this is kind of what I was speaking to earlier is that when you're working with a simple system, it's simple, it's easy to work with and then the complexity starts to grow, it's never a good thing when you have to reach for a more complex tool to manage the complexity. It's a hallmark of a good system and that it can scale with you from a very simple and easy use cases to actually being able to handle very large and complex use cases but your API doesn't have to change and your usage doesn't have to change. If you have a tool that can actually scale with you from a one liner to a hundred thousand liner, that reflects very well on the design of the tool. I think you see that with things like Ruby, you see it with things like Clojure. You see it with, I would say there's even people writing like Haskell, shell scripts now but not so much with like C++. I think the analogy is very similar with microstates in the sense that when I'm looking for evaluating a language, it's not the only thing I look for but I really am looking like how is this going to work for me as a one liner? How's it going to work for me as a hundred thousand liner? If the answer is pretty consistently, then that's something that is going to get a lot of bang for your buck, so to speak. If I invest the time in learning it, I'm actually able to reap the reward of having a tool that's got my back on a whole bunch of different use cases. We talked about, in React, if I'm using set state and that's kind of a sub case of component state because I would say that in the previous systems we talked about -- Ember, Vue -- they have components state but the component state is a little bit more rich in the sense that you've got computed properties and what have you. But if we look at a system that externalize a state like redux, where you have a global state atom in your application, at least that's the way most of the redux applications that I've encountered behave, what does it look like for you? TARAS: I think it's a little bit challenging when talking about redux is redux conflate a few different things together. I think it's helpful to split those things up, so we can talk about them separately. One of the parts is how the state is delivered to components. The way that redux does is the instance is this created so every time you use connect, you essentially wired together. You can connect through the context or... I'm not sure. I think they have an observation mechanism that's internal to redux as well but they essentially connect components to the store and then they view that to deliver the state. It's kind of worth pointing out that for that like microstates bindings for React actually give you something similar out of the box through context. For those who really like the ergonomics of connect, I think it would be pretty easy to make that available for microstates. Usually, we don't even know why they wouldn't be available. CHARLES: But I do think that connect can be problematic like you can encourage you to not make components that are reusable and have isolated state. It's very easy to hitch yourself to the redux store and now, you don't have components that are shareable. TARAS: I think I would personally prefer to pass microstates instances through props because of the stability that's built into microstates and structural sharing, you can get some free optimizations and allow it to use functional components in more cases like out of the box but some people who are really like redux, they really like connect. Although it might be my personal preference, there's no reason why that wouldn't work if somebody wants me to connect function and make it available for people. CHARLES: Right and I think, there's a happy medium there too, right? TARAS: Yeah, I think -- CHARLES: -- You can connect components and then fan out that state to a set of functional components that are not connected. TARAS: There are some places where microstates and redux are very similar. When you're using in redux, you have this dispatch mechanism, where you essential saying, "I'm going to dispatch this action and your action creator is going to create an action for you with the payload," and then you're going to match that action to a reducer. One of the things that I kind of hear redux people really enjoy about redux is the one with data flow that dispatch the action and then, it reduces this next state and pushes that through and you have this kind of ingress point where everything is going through this one point. I think what's really interesting with microstates is you essentially get that. That's exactly how microstates works, in a way. The only difference is that the API is different. Any action that you invoke is going to go through a single entry point, which is going for you. Because we know the structure of the data, we know how to transition that state for you, so you don't need to reducers, so you're just defining your transitions or use the built-in transitions and then when you invoke them, we know the path. We're essentially forming for you. The path where you invoke the transition, conceptually, it kind of forms the name of the action that you are invoking. The path refers to a place where the state is going to be transitioned, then you have your transition, which is the actual reducer for that part but it's contextualize, so you don't have to think about how you need to transition that state in a great, global redux state. CHARLES: There's no matching. The matching is automatic. TARAS: Yeah, the matching is automatic, so you get that same single ingress and one directional dataflow. You get those mechanics except the APIs that you use, instead of writing the actions yourself. Instead of writing, we just use yourself. You get to use microstate types. I've heard some people who use redux who are like, "I really love the fact that microstates has types," but other people don't like types for whatever reason. Microstates comes with 'from,' which allows you to take a POJO and from that POJO, it creates a microstate and then you can invoke transitions the same way as if you had a type microstate. The only thing you don't get is you don't get to create your own transitions. You have to use the transitions that are provided for the primitive types. CHARLES: I think that there's a couple of benefits that you'll realize for free. There's laziness, reducers by default, or eager. When you dispatch an action, it will run against every reducer in the store. If the reducer matches, you're going to run the computation that's associated with that reducer. Microstates by contrast is lazy. Basically, until you try and read the property that is affected by that reducer, the reducer won't run. There's some ways that you can get around this. When you're using redux and first of all, you can actually have your reducers return objects that have getters on them. You can realize some of that laziness but again, it's work that you have to explicitly put in. I think, didn't you actually say that there is a package of plugins? There are plugins. There's basically a set of libraries that you could bundle together, which would give us an experience similar to using microstates. TARAS: Yeah. If you wanted to combine redux and reselect and immutable JS together, you can get some of the benefits, except this benefits are not integrated that well because they're still separate systems that you are essentially using together. Also, like microstates, it's four times smaller than redux and reselect and immutable JS combined together. If size matters to you and ergonomics matter to you, you actually can get a lot of ease out of using microstates while still maintaining the benefits of having redux. CHARLES: But if those things, those packages, like reselect and immutable JS, are things that are familiar and you naturally gravitate for it, then you'll probably absolutely love microstates. Because honestly, one of the ways that I think about microstates is like, what if you could have immutable JS, if there was no cost for composing the types like list and record. Immutable JS has come a long way since I've last used it or it's evolved since I've last used it but I think there's still only about four or five basic types and actually, making your own new immutable structure, your own custom type with its own custom methods that still get the benefits of structural sharing and laziness that you have on immutable JS is not something that you can do. But you could think one way to think about microstates is an immutable JS where you can make any type that you want. You're not just constrained to the record types and to their list types and set types or map types. TARAS: It's worth pointing out that at the moment, microstates doesn't map perfectly to immutable JS simply because immutable JS has certain optimizations for managing lists that kind of a great value of immutable JS and microstates doesn't have some of those pieces but -- CHARLES: They're definitely on the road map. TARAS: Yeah. Because microstates is abstracted high enough, that we can actually change internals and some people who are using microstates now, they will get benefits of ergonomics and there's already performance benefits from the stability that microstates offers but there will be a time when by upgrading to newer versions, you will not basically, need to change anything in your op but you will get the benefit of improvements to performance that we will introduce over time. Some of those improvements might come from what we will learn from immutable JS. CHARLES: Right. I have a couple of thoughts before we wrap up. What are the ramifications no matter who you are? What kind of development background, some of the benefits that you'll experience with microstates that might be a pain point or something you hadn't thought about where you are currently? A couple of things that I have jotted down is first, and this is what brought it to mind is talking about stability. Something that you see in a bunch of frameworks is having to manually track the keys that are associated with data. If I've got a list or I've got an object, being able to say, if that object changes, then I need to actually have some sort of key object, which effectively amounts to a hashing function to say, "Did it really change?" Because no matter what system you're in, you need to know how you're going to re-render. If the reference to this object changes, then the default thing needs to be, "I need to re-render it," right? You see this in Ember, in Vue. In React, there's this ability to pass a key or ask the question, "Should this component actually update?" and with microstates, that's much less of an issue because basically, it keeps the key tracking instability for you. If you are using a model with microstates, if you think of an object as a graph of nodes, no node in the graph will change unless it absolutely has to, at least that's the goal. We still actually have some work to do when you're running queries against the state of a microstate. We can cover that later but that's most largely the way it is now and definitely, the way it's going to be going forward is you don't have to do any extra work as a programmer to figure out what has actually changed. TARAS: That opens up some interesting opportunities. Imagine if you had a rendering engine that did not expect side effects to be significant and you could just say, "If I know whence they'd changes, I will then re-render that." That will be really interesting exercise, seeing like what would that look like for a performance perspective, if you have a very clear picture of what has actually changed and what part of the DOM as a result, need to be updated without having to do diffing. The [inaudible] you could actually do a diffing at much higher up. Actually, [inaudible] to diffing because you know what's changed but you can push a lot of assumptions higher up on the architecture stack. CHARLES: Right. That's actually one of my favorite thing about microstates and one of the unwritten values is like triple equals used to work everywhere and by and large, it does. It's usually simplifying but when you don't have to manually tell the computer what equivalence looks like, you can just say, "Look, are they the same object? They're not the same. If not, then they're not," and keeping that consistent is huge. TARAS: I think this is a good segue for us to kind of bring this conversation to a close and also, kind of set up potentially a third full-on conversation, which we could talk about actual architecture of microstates and design decisions because for people who just want to use microstates, they don't need to know all these details but for people who are curious, they might actually want to understand what are the considerations that remain when we were designing microstates, so maybe in a next conversation about microstates, it could be about architecture and the pieces in microstates today and then where we are going with microstates and what it could give us long term. CHARLES: Yeah, I like that idea. It is a plannable subject that we've been talking about internally for the past two years, so it makes sense that there would be plenty to speak about on the podcast. There is one other thing that I did want to bring up and that is, I think enabling to have a state solution that is composable because it allows you to think about your state first. Because really, if you do have a functional UI, where your view is a pure function of the model, that your view follows the model and so, if the view follows the model, then really, the thing that you should be thinking about first is the model that's going to be required to drive your view. I shouldn't drive. I should say derive your view because that's the primary artifact of which the view is nothing more than a function. It's a reflection onto a surface. I don't think that we have a state management solution yet, that enables that mode of thought, where I'm thinking about my prime artifact first and working forward rather than thinking about my secondary artifact and trying to kind of wishy-washy way, work backwards and reconstruct the primary artifact. I think that we've talked about all the development ergonomics and I think there's a mechanic of thought there that's enabled by this that I hope to see in more and more applications. TARAS: I think that's a really well put. I think that's something that I've been thinking about as well, as how do you convey this shift that microstates allows in terms of how we're thinking about architects and the application. For some people that value, the model, like they'll find that shift easier but regardless, I think that making that shift has a potential of simplifying your view dramatically and I'm very excited about exploring this further and having more conversations about this. CHARLES: Yeah, that's where we really kind of open up the conversation about state machines, which is also central to the conceit of microstates and using state machines as an incredible design tool but anyway, we can all get into that later. You heard it here folks, Episode 3 is coming out, although probably not for a while. We're going to be mixing up and we will be talking about microstates at least for a while. I understand that next time, we actually teased it but we based on how much material there was on microstates, we ended up packing in a second episode. We teased it last time, we're going to be talking next time about running an online conference with Twitch, so definitely look for that. Thank you, Taras. Thank you, David. TARAS: Thank you. DAVID: Yeah, it's been great. CHARLES: This is a wonderful conversation and as always, we are Frontside. As I mentioned at the top of the show, we have availability coming in August, so if working with us is something that you would like to do, we have a range of services, please get in touch. You can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io. That's it for now. I guess we should also mention that Taras that you are going to be giving a talk on microstates at ManhattanJS. When is that? TARAS: On August 8th. CHARLES: I will be giving a talk on microstates at ReactJS Austin on Monday, the 6th, so that is right around the corner. I'm excited about both of those talks, especially following so closely on the heels of the TorontoJS meetup talk, which I understand is... Is that posted online yet? TARAS: It's recorded but it should be coming out soon. We'll definitely tweet it out. CHARLES: Okay. All right. Look for that and we will see you next time.

Wir schaffen uns einen Überblick über das Angular Framework und auch über die nächsten Episoden: Die Komponente ist ein elementarer Baustein einer Angular Anwendung und definiert den Inhalt deiner Anwendung. Eine Direktive sind Befehle, die das Aussehen des Templates anpassen und kann auf ein HTML-Element oder Komponente angewendet werden. Für die Bereitstellung von wiederverwendbaren Methode oder zur Datenhaltung werden Services in Angular verwendet. Der Angular Router ermöglicht die Seitennavigation ohne Server-Request. Durch Module ist es möglich, die Angular Anwendung in Sinnabschnitte zu gliedern. In Angular gibt es zwei Wege, wie Formulare aufgebaut werden können: Template-Driven-Forms und Reactive Forms. Durch Pipes können wir Rohdaten von der Ausgabe formatieren, ohne die Rohdaten anzupassen.