 Let's go. You see this in the track or academy? Just wait a second, it takes a while. OK, you can start, Cameron. Hi, everyone, welcome to the webinar on what's new for developers in the latest version of the application platform from DHS2. We hope that you're able to join us and learn about some of the exciting new features that we've added to several of the tools that we build for application developers. I'm also excited to start off this webinar with a presentation of our newest developer advocate who has joined our team just this month and is probably very overwhelmed with everything that DHS2 encompasses. But we're very excited to have him on board and to see what we can do to enhance the community of developers and the learning material and the connection that we have with third party developers all over the world. So with that, I'll turn it over to Hermann to introduce himself very quickly. Yeah, hello, thank you, Austin. So my name is Hermann Biscousso, you know that. So I just joined the DHS team as a developer advocate. And I'm originally from Buenos Aires. I just wanted to tell you where I come from, right? But I live in Madrid with my family right now. So just to give you a bit of information about my background, I was a computer nurse since I was around eight years old. But I have a formal computer system education at university. And after focusing a lot on software development, I had the opportunity to create and run developer advocacy programs for multiple companies. The first one was a company called DB4O, where I was running an open source project, which was an embedded database. And that was it for me. I decided that I wanted to do developer advocacy instead of focusing exclusively on software development, right? So I enjoyed a lot the interactions with the developer community within an open source project that was especially interesting. So I decided to focus on those roles. And the last one was at Amazon. I was actually a developer evangelist in the Alexa team. They probably heard of the voice assistant, right? So the question is, why is this appealing to me? Why am I interested in all of this? So sometime ago, I read a book called The Wisdom of Crowds, where there was some farmers in a rural area participating in a kind of contest. They had to guess the weight of a goat, right? So everybody would write down in a piece of paper how much, what was the weight of this goat? And suddenly the winner was the one that had the closest number to that goat. But someone decided to average all those papers, to create an average of the weight. And that number was super, super, super close to the weight of the goat, even better than the best guess, right? So this is just an example of how the collecting wisdom can be very powerful. And that's what really fascinates me. So my job, among other things, would be to make sure that we as a community empower ourselves to get the best out of DHS2 and work together in supporting each other. So that's my main concern right now. I'll make sure that your voice is heard as a developer, that your feedback translates into positive changes, that the features that you need are incorporated into the queue, which is super important. And of course, that your contributions don't go unnoticed. So we will be running special programs so your contributions are visible, okay? So I'm sure I will see some of you face to face when we have a chance to meet, they hope we put COVID-19 behind and we do some real live events. So please join me and let's make this community rock together. Thank you, Rossin. That's all I have to say for now, but I hope that's an acceptable intro for, so people understand what I'm really doing here, okay? Thank you. Absolutely, thank you, Hermann. And I know we can't hear our audience, but I'm sure they're all applauding and cheering wildly because I'm excited and I'm sure that they are too. I wish that we could hear them. So if you're excited, please let us know on the community of practice. Thank you. So I'll be monitoring the entry and the community of practice. So if you have questions, please send them there. Yeah, I was going to actually also allow this, yeah, share this very quickly before we move on with the webinar. We do have a community of practice thread for this webinar. So if you go to the community.dhs2.org, the top entry here, it should be the top for a little while, is this, it's talking about this webinar and you can actually, that's where you're probably watching it right now. We are monitoring this. So if you click this reply button and type a reply, we will be able to answer it live on this webinar as well. So please, if you have any questions, if you're excited about Hermann joining the team and what we're going to do together as a community, please do click reply and add your feedback on that thread. So with that, I'll turn it back over to the presentation. I'm going to just very quickly for we have a big group of a big developer community and there are people with different levels of experience with DHS2 with application development. So I'm just going to give a quick kind of rundown of what an application is in the DHS2 ecosystem, what the application platform is and the different components within it. And then I will turn it over to some of my colleagues on the development team who have built some of these great features that we'll be sharing with you today. And what we'll be going over is the new features that have been introduced in the last several months, three or so months, particularly with the version eight release of the application platform. And what that means for you as developers. So with that, I also wanted to take this opportunity to very quickly show the new application management app in DHS2 237, which is coming out today. So in DHS2 237, if you go to app management, you will see something that's very different than the app you saw before. There's a lot more information about the different applications that are currently installed, including the core applications. So the ones that are bundled automatically with DHS2 when you install it. And in particular, you'll see that on the core apps screen you can actually see when new versions of those core apps are available. This is part of an effort for the core development team at the University of Oslo to release more quickly applications and allow them to be installed into DHS2 servers that have been maybe a little bit older. So this will allow you to adopt just a single application, much lower risk to adopt to that new version in DHS2. And that's all made available through this app management app and the app hub, which is at apps.dhs2.org. You can also see a lot more information about the apps that are coming from that app hub, such as description, screenshots, different versions that are available, contact information, that type of thing. So I wanted to take that opportunity to talk about the app management app, but to take a step back, what is an application? So the nine squares in the top right corner of this screen is the application selector in DHS2. If you open that up, you'll see a list of all the apps that have been installed. And there are many more that are available as well. I'll actually show this to you quickly so that we can just see it visually. So if you click on this top right here, you'll see that these are all of the applications that are installed in this DHS2 instance. Some of these are bundled and available when you install DHS2 itself. Others you need to manually add to the system because they might be developed by any of you out there. So if we go to this app management application, which is, as I mentioned, has been significantly improved in the 237 release, you can see that we have the ability now to update the app management app to the latest version. There might not be a version that's later than the one that's currently installed. So we can go ahead and click update to latest version. And now we've actually updated this application very quickly from the app hub. So this is what a DHS2 application is. There are many others that might be installed in your system. As I said, many of these are things that you might use to do data entry or to do a maps application, yeah, to analyze maps in DHS2. It might also be something that a third party developer, not the University of Oslo has developed. We have a few that are installed in this example. One of those is a training application, which is a very cool piece of technology that allows you to walk through the use of different applications in DHS2. But all of these are, and this one's gonna take a minute to load, so I'm not gonna wait for it to load, but all of these are different DHS2 applications that you can build using the tools that we provide in the application platform. What is that application platform? So there are many components within an app. If you've been a DHS2 developer for a little while, you've probably seen this slide before. There are many different components of what makes up an application. And importantly, most of these things are common to all applications. So they don't need to be re-implemented in every app that you build, every app that we build. And so instead of having to construct an entire web application that takes care of all of these different things collectively, in every single time we build a new application, or you build a new application, or someone in the community builds an application, we have extracted out all of those common pieces and provided them as the application platform tool and allow the apps to be much smaller, easier to manage, easier to maintain, and also more consistent because all of those common pieces are shared between the different applications. And importantly, this is something that we use internally in the University of Oslo and the 34 applications that we manage. But it is exactly the same that is provided to anyone else who wants to build a DHS2 application. So the long-term goal of this app platform is that anything that the University of Oslo and the core developers can do to build a core application should be just as easy and available to third-party developers to build that same application or something that we haven't necessarily thought of or that is applicable to a slightly different use case. That's the long-term goal. And there are three major components of this application platform when you actually get down into how to use it to build an app. The first is what we call CLI app scripts and that allows you to basically gives you tools at development time to more quickly and more consistently develop, test, build, and deploy your application. Birkel talked a little bit about deploying. There's two different mechanisms for deployment from the CLI apps scripts. There's one which installs your application directly into a live DHS2 instance. And then what Birkel talked about is a new functionality to publish directly a new version to the app hub which then makes it available in that app management app I showed earlier to other DHS2 instances in a while. The second component of the app platform is the runtime which is a library that helps you interact with the DHS2 server and the functionality of the app shell. This has no user interface. It's just a functional library that lets you kind of hide away a lot of the complexity of talking to the API and those types of things. And Ismay will talk a little bit about a new functionality in the app runtime that allows caching of data automatically when using the use data query hook in the app runtime. The third component here is UI. We won't talk much about UI today because we're focusing on some of the other functionalities that have been added to the CLI apps scripts in the app runtime. But there is an entire UI React component library and design system which implements the DHS2 design system and gives you reusable components to use in your own applications. An important one that has been added very recently to UI that may be of interest to many people is the data table components. So if you're interested in that, if that's something you might be looking to use in your application, go to developers.dhs2.org and go to the documentation for the UI library and you can find some examples of how that is used. And if you have any questions, please post them on the community of practice or in the Slack developer workspace and we will be happy to answer that. We'll probably have a webinar specifically on UI components as we are adding a few more in the near future as well. And we'll talk about that on a separate session. So now to talk about some of the new features that have been added to these app platform components in the last few months, I will turn it over to several of my colleagues. First off, I will turn it over to MediRemi who it will talk about deduplication and proxy commands. And this is really important because this works around the cookie issue that has been plaguing many developers for quite some time because Chrome has started to deprecate the cross site cookies that have enabled a local host application to talk to a server that's running on a different domain name. So with that, I'll turn it over to Medi to talk a little bit about deduplication and proxy commands. If I want, let me just share my screen. Okay. Can I want to see my screen now? Just be visible. Yeah, cool. Cool, so I've got... Sorry, can you guys hear me then? Okay. I don't see your screen. I don't know if the rest is using it. I do. Okay, cool. I'll continue and hopefully it will sort itself out. So yeah, hi everyone. I'm Medi and I'm here to talk about two new features which are both implemented as commands in the CLI. So they should all be usable right now if you just upgrade your dependencies. And the first feature is the proxy server. So as Austin said, unfortunately, we've had issues with removing support for cross site cookies for security reasons and that's going to affect many of your workflows. The development is going to serve an application locally at local host 3000 but then connect to an external server which might be your production server or another instance like a staging server. And unfortunately, since Chrome version 90 cross site cookies where you're connecting from a locally hosted app to an external server have been dedicated and don't work without workarounds. So previously we recommended adding these command and options to your Chrome flags which did work until this September when Chrome 94 came out and moved these options. So now we've got a new recommended workaround which is our new proxy server and what that does is it allows the application to talk to another server locally, so on localhost 8080, which then talks to your external DHS to instance and by having both your application and the proxy on localhost, it rather won't complain as cookies on the same host. So to use it's pretty easy. You just make sure that your CLI app script dependency is version 8 or greater. Then you add the proxy option to the start command and then you pass the URL of your external server. I've got an example here with a URL but of course for your own server it's been your own link and it'll work the exact same way. So by default the proxy will be on localhost 8080 but you can change that and if you've already got something running on 8080 or use 8081 and so on. So once you run the start command with the proxy option once you have your login modal you'll just change your server to localhost 8080 instead of your external server and everything should work as it normally does. You should not see any difference if you do piece file a bug and it will sort that out for you. Now I'll do questions for this feature at the end of this presentation. So I'll go through a lot file validation now and then any questions for the proxy will also be at the end of this presentation. So when you add dependencies to your package.json file your run.lock file and your node modules folder will be updated to contain all dependencies and sub-dependencies required by your application. Now sometimes that means that if two dependencies depend on the same package you might get multiple versions of that package. For example, if you have the app runtime version 3 and the CDI Apps Scripts version 8 a new lock file will have the app runtimes version 3 and 3.2 because you have two sub-dependencies in your package.json. Even though they're not explicit in your package.json that's how nplr yarn will resolve it for you. So although this is harmless most of the time some dependencies do need global shared state or context and context is shared within one version of the package. So if you have multiple versions you have contacting global state. If you don't need this the app runtime is one example of a package that does not work with multiple versions of present because we need stateful things like alerts for requests and other things that make your application work well. So unfortunately yarn v version 1 doesn't deduplicate automatically but yarn v 2 and v 3 do do that. Since we don't support yarn v 1 what we've done is implement this validation deduplication for you automatically in the start and build commands. So right now while you're doing that for certain libraries that we know are vulnerable to this issue or are susceptible to this issue such as app runtime, UI and React where you only want one single version. So when you run start and build your dot file will be automatically validated and you'll either get a warning if using start but if you run build then it will actually resolve those issues for you. So in general whenever you run the start command and we have other validations we only show warnings or for build that we do fix those warnings and it just makes your life easier that way. You can also run deduplicate manually but in that case you will have to run yarn install afterwards to sort out your node modules folder. If you run the build command it will do yarn install after deduplicating so that should handle everything for you. So in general you want to run build but if for some reason you want to check your dot file you can run deduplicate. And I'm happy to take any questions you have right now. We don't have questions from the community right now. Okay. Yeah, thank you very much Madi. Again to everyone else if you have any questions please post them on the community of practice in that thread and we will respond to them. I saw that there was a number of welcoming posts for Hermann already so great to see that. I do see one person typing and they're going to ask a question or add another congratulatory welcome to Hermann but we can get back to that in a minute when that... We got it. Can you update the tutorials for our platform? I followed the tutorial but still was not able to install Dev environment. Also it would be nice if you will add ask other core DHS to Dev to check from time to time the forums and answers to the questions. We will address that as we go forward. Yeah, absolutely. We do need to update some of the documentation on the app platform and some other developer documentation. We are continually growing that so you'll see more and more coming through. If you have any specific questions that you were struggling with to get the Dev environment set up please share them on the community practice and tag myself or Hermann and we will respond and make sure that that gets addressed. If you already have a post that's open please share it as well and we'll make sure that we get to that. Thank you. Next up we have command line app hub publishing and we will move it over to Birk to talk a little bit about that. Thank you. I'm Birk I'm a front-end developer at DHS too. You might have a new command to the CLI tool that you hopefully have some experience with and you can create your apps with. Here you can see the documentation. Can you see my screen now? Hopefully. Maybe zoom in a little bit. Here's the documentation for the D2 Apps Scripts command. This is done to help you upload apps to the app hub. Hopefully you want to share the app hub here. This is appstages to the app hub and you can log in and upload your own app. I'll show you how to use this command to upload new versions. Here I have a sample app that I want to add new versions to. Instead of having to manually upload new apps that might be annoying. Sorry for that right-click. My mouse is a little sensitive. Instead of doing this manually we now have a command you might have seen this before I presented this during the experts academy this summer but we will re-trade this and we have made some improvements and there's still some new stuff coming. So here you can see the visual studio code of this sample app. It's very simple. It's just a platform app in it through the D2 Apps Scripts in it. Here we have a D2 config file. So I've added the title to not have like in the package you need to have like a dash we call it Webinar app and then you need the minimum DHS version this app is compatible with to be able to upload it to the app. We need two other major pieces of information here. The first one is the ID of the app. So after you upload it to the app you can go to your URL here and get the ID of the app. We will make this easier to find but right now this is the way you do it. So if you click here then you add an ID field with this ID. So this is to be able to when we upload to match this app in the app hub. And then to be able to authenticate to the app hub you go here to the top right and you click your API keys. And here you can see that you can create an API key and it's important to keep it in secret and secure since this you don't want to get that compromised. So you'll only be able to see this once and you click for it here and then I go back here and here you can see my terminal. So here I can do export so I will make this environment variable which is the best practice here token and then hopefully you can see it is this small as well maybe I will try to make it bigger. So here export D2 app hub token and then we paste in what we got here. And then we can do so if we now do yarn version so now we simulate creating a new version of this app that we want to upload right. So now we got a new version and the package JSON is uploaded and then you do yarn build to build your app. I've built it now but let's do it again. Then after this we can upload it to the app hub by using the new D2 app scripts command D2 app scripts publish so hopefully this will run creating archive so if you're doing D2 app scripts publish and the cool thing about this command is everything is read from the package and the built scripts. So you don't have to pass anything any params to the command everything is done for you and the version is uploaded to the app hub. So if we now go to the app hub again your apps webinar app and you can see we have a new version so hopefully this will make it easier for you to upload your apps you can even integrate this pretty easily with GitHub actions since everything is done or read from the commands you don't need to pass anything you just need to set up the secret token in your secrets on GitHub. There's if you go to developerstages.org you go to docs and then you go here for continuous delivery to app hub you can follow a guide that will take you through some of the process I did now to get your API key and then you can set up the ID and here you can find a sample GitHub action word flow you can paste into your repository and then when you create go to GitHub and you create a new release it will automatically build and publish your new build to the app hub. So this way you can integrate our own continuous delivery process and have your app updated and ready and you don't need to go through the manual process of uploading new versions or emailing versions to others through email or any other way. So hopefully this will help you be able to have your app ready and updated. So I think that's it for me if there's any questions we will answer them and again I want to refer you to these documentation pages here's both one for submitting an app to the app hub and please follow the guidelines that is linked when you're uploading an app so the uploading an app here there's a link to the app hub submission guidelines so we can easily approve your app and then you can utilize these commands in your further development process. I think that's for me. That's great we don't have questions in the community so I think we can move to the next presentation if that's fine Austin. Yeah sounds good again feel free to add any questions you have to the community practice and we'll answer them here but thank you Birk I know that's something we've presented before but I think it's really important to highlight that it's a very powerful way to standardize and automate the way you deploy versions consistently to the app hub it's really good to see that again and next up we have in-memory caching and stale wall revalidate which will be presented by Esme so I'll just go ahead and turn it right over to you Esme to talk about that Thank you Austin yeah I will briefly talk about the changes that we've made new features in the app runtime I will share my screen in a second so this is the app runtime repository some of you might have already seen that we've enabled stale wall revalidate and queried into application in the app runtime so I'll briefly go through how it works what that means for detailed information the change log contains detailed instructions on everything that has changed what you can do to solve dependency issues if you run into those so make sure to take a look there these changes were introduced in version 3 and I hope this text is readable see I'm getting a message that my screen sharing is paused let me see just share my screen still looks now we can see your terminal sorry this is a text editor yeah is that a text readable yep okay this is a very simple data fashion component from quite similar to components that you've written yourself where you're using data from the back end use data query to fetch it so what we used to do is if the hook was loading loading would be true you'd render say a loading spinner and then you check for errors and if everything's okay you'd render the data and let's say that the data is refreshed say someone does something click some button and the data is fetched again what used to happen is that loading again etc etc so basically it would always show the loading spinner so what we've enabled now which is called civil revalidate is that as soon as you have data it will skip the loading state show the old data while the new data is being fetched it will just swap out the old data with the new data so your users will only see the loading spinner when the initial data is being fetched and after that it will just show the still data briefly and swap it out with the new data you don't have to change anything in your code to sort of opt into this new behavior it's the new default so that means that for the new runtime as it says here loading will only be true during the initial load now it's possible that you want to opt out of this behavior say you have where it's really important that it only shows the correct data and that you say you rather have a loading spinner in between that's possible for that we have the fetching property which is new since version 3 and fetching will basically behave like our old loading property so you can just get it from the hook here and if you swap out your loading usage with fetching it will basically show the loading spinner every time again so it's a very simple change but it means that your app in general will feel more responsive because you don't have the loading spinner every time and you can just keep rendering data one other thing besides this change is say you have this component and it has a query and this component is duplicated throughout your app say you have like 5, 6 of these components throughout the app so it's something like like this so for example for example use the same data component but we're rendering it 3 times here so what used to happen before version 3 is that it would fire up 3 identical queries which is a bit of a waste so what we're doing now is we're deduplicating queries so as long as there is a query in flight and there are other identical queries happening at the same time then we just deduplicate them so we just send one request you don't have to do anything for that it happens automatically it will only deduplicate requests that are exactly identical so you shouldn't run into anything any issues with because it differs slightly because as soon as it's different you don't want to deduplicate it and that's basically it so for any detailed instructions I encourage you to take a look at the changelog and we'll make sure that the documentation is updated so that it reflects the current state and if you run into anything that Prince wants to know and I will take care of it I don't know if there are any questions no, we don't have questions right now there's a question in the community of practice related to authorization of apps that's unrelated so I think we can move forward thank you very much nice presentation next this way next we will turn it over to last but not least progressive web app support which is a really big topic that we will introduce here today has been added to the app platform and I will let Kai go ahead and give an introduction to progressive web apps in DHS2 applications thanks Austin yeah, there is a lot that could be said about the things that we've been working on here but I'm going to keep it a little bit short today and I have prepared a blog post that will cover things that I'll talk about today in a bit more detail and even a few more things that I'll link to in the community of practice when I'm done speaking so you can refer to that if you're curious about learning more also coming up there will be some more detailed blog posts about the tech design that we've done behind it that you might find interesting but for now I'll just describe a little bit about what's available and then point you to some resources if you're interested first thing that I'll mention is that PWA means progressive web app which can mean a lot of things but for our purposes it means that the app is installable like you can add it to a computer or a mobile device and so it'll behave a bit like a native app but also most importantly that it's offline capable so you'll be able to take these apps offline and access them through the internet connection which should be a big deal for apps that are expected to be used in low internet connectivity areas or in places where the connection is kind of inconsistent so in the dashboard app which in 237 will be using these PWA features I'll use this as an example of the things that we have available I'll show you now that in the old version of the dashboard app this is in 236 before it's using the PWA features if I use this developer tool to simulate being offline and reload the app we'll see that we don't get any service the app doesn't run we don't get the scripts that run the core functionality if we go to the new one that's available in 237 what we have is that when we go offline I'm running this one on localhost which is why you saw that login screen what happens when we go offline is that we can still see the application and this dashboard which we've saved offline now not all the dashboards are saved offline and that introduces the next thing that we have as part of the suite of features that we have here we call these dashboards here or the thing that we wrap them in cacheable sections to be able to save an individual bit of content in the app offline without saving all of them offline is what we've enabled so that you can save an individual dashboard without saving potentially dozens or hundreds of dashboards so this one's already saved offline here but when you use a cacheable section and wrap a section with that what you can do is in the dashboards app here we have this make available offline button what that'll do is it'll reload this section use this mask to block interaction with the screen and then we have a tool that listens to the network requests that are sent as this section of content loads and I'll save it in an offline cache so now we see this notification here that this section has been saved offline and if we simulate being offline with the developer tool and reload the app we can still see this content that we have saved so in the app platform we made a React API to enable these cacheable sections for your apps as well and I can show you a quick example of what that code looks like in a moment yeah I'll go ahead and do that now there are two main features there's a hook that accesses the controls for starting a recording to capture that section offline and then around this simulated dashboard here we have this cacheable section wrapper that goes around it and controls reloading the section and putting the loading mask over it so you can go and check out the blog post to check out more details about that but that's just a little preview of what that looks like and another feature that is part of this suite of tools let's see there we go hang on I need to move my zoom tools a little bit here okay you can also see this offline indicator here this is another tool that's available with the suite of offline tools that's available in the runtime is that we have a hook that can tell you whether your device is online or offline at a given time so we have this indicator in the header bar up here tells you that we're offline in other places around the dashboard app like in this button here some features are disabled while offline like creating a new dashboard or filtering the dashboard so that's useful if you're just working with functionality in apps that should be offline capable one thing that you might see as you're working with a PWA app is that updates to the app need to happen in a new way because this app caches the core scripts that run the app and they're kind of installed in the browser and run from there instead of being accessed from the server whenever there's a new app available you'll need to install those new scripts to run the app so you see an update or a prompt like this that gives you the option to update the app and when you click that you can reload and then you'll have the new version of the app you'll need to do that the first time that you upload and use the offline capable version of an app these tools have some drawbacks and catches and need to be designed around so they're provided on an opt-in basis you opt-in by setting a setting in your d2.config.js file the option is pretty simple it's just adding pwa enabled is true and then you get the basic offline functionality the offline caching tools you'll need to do a bit more setup if you're using the caching sections but that's described in the documentation here there are some other caveats about security as in the data that's cached offline here can be inspected by a malicious actor who gets access to a device so you want to take extra precautions when you're thinking about applying this in an app you want to make sure that you have good safety practices in place if this is going to be used in an app that's going to be used on shared devices and you want to be aware of the potential drawbacks there there are some tools that we have here for example if you use the logout function in the header bar it will clear the sensitive data that you might have cached offline and then when you log back in you'll see that the cached dashboards are no longer available the same thing happens if you log in here the sensitive caches will be cleared coming up next in the PWA features will be encryption of the offline data as the first thing that we'll be working on so that it can handle sensitive data on shared devices better we'll also be working on some cached normalization to improve performance and storage capability I'll be working on that blog post describing the tech developments that should come out in the coming week or two and then to wrap up I'll just share some links to this blog post and the relevant documentation in the platform and run time documentation sites and I'll add those to the community of practice I'll just take a peek here see if there are any questions looks like we're looks like there aren't so that's all for me I'll pass it back to the hosts thanks a lot thanks a lot Kai as you mentioned there's a lot that we could talk about how that works under the hood and some pretty cool technology that we're using to enable offline capabilities in our applications in a generic way and I'm really looking forward to the technical deep dives that you're writing about that which will be really cool to share with the community and I think it's just even if you don't know anything about DHS2 it's really cool technology and stuff that we're working on I did see that there was there are two people currently posting something in terms of questions first one is for Ismay does the refetch display a loading indicator using a refetch component I'm not sure exactly what that means but does that mean something to you Ismay? Not the refetch component but I assume that the question is asking also whether the loading state will always be triggered when you're refetching so it depends because currently with a refetch you can pass new variables so you have some variables in your query so that can mean that basically it's a different query it's not exactly the same as the previous one so there won't be any cached data so that means that the loading state will be triggered again it's also possible that you're refetching without passing any new variables so if it's just a refresh of the same data so if you're doing that, if you're not re-changing the query then it will show the stale data by default basically show the stale data while it's reloading so it depends on whether you're refetching with new variables or not I guess that's what's meant with a refetch component basically the loading spinner if not then let me know but that's basically what will happen Thanks if anyone else has any questions please feel free to post them on the community practice now or in the future as well so this will be available as a recording in the same community practice post where you're probably watching it now we will have the YouTube video of this webinar available and so if you have any questions when you're watching this video after the fact or if you have any questions when you look through the documentation or try to use some of these features please feel free to post them there on the community practice you can also post them in separate topics if they're unrelated or not directly related to the content of this topic Herman is there anything else you wanted to talk about in terms of the community or next steps I know we have a few things that we're kind of looking at but if not we'll probably wrap it up first of all we'll be trying to improve the developer journey to make it smoother for everybody and then working on specific programs to enhance contributions and to also recognize contributions but I basically have one very small comment which is feel free to PM me in the community of practice if you feel like you have ideas on how to improve the community on what kind of programs we should be working on etc. very glad to receive feedback on how we can make the community better together just that yeah great really looking forward to it and thank you very much to all of our presenters today really exciting features that we've added to the developer tooling and really looking forward to seeing what apps are developed using these new features again please feel free to have on Slack or on the community practice to the rest of the team and with that I think we will wrap it up for today so thank you all very much for joining us and we look forward to seeing you next time thank you