![]() Instead of using JSON.parse(), there is an asynchronous way of parsing data into JavaScript object, that is by using. If we convert the response onto JavaScript object using JSON.parse(), we will not be getting any data as the fetching of data is done in separate thread, where the response is received as a callback. The response that we receive however is a Promise, thus it is asynchronous in nature. See, JSON.parse() is synchronous in nature, hence it runs on same thread as our main program. Here you may think of using JSON.parse() to parse the incoming response, but that is very not true. catch() methods in it (Alternatively, using async and await will also work).įirst, if the Promise returned by the fetch method is fulfilled, then we receive a response which needs converted into JavaScript object before we use it in the application. We know that fetch returns a promise, thus we can make use of. The fetch function first has to go out to the resource provided by GitHub. ![]() Hence, we make use of fetch() method in apiCall function. The main objective of this function is to request data from the API. Lets see what we need to do in this function. We see that the function apiCall is not created. We also need to select the form as we need to add the submit event listener to it so that we submit the username to server. They being the wrapper division for user avatar, the username division, the span tag where we display followers, repositories and following of a certain user and finally the overlay that is shown if the entered user doesn’t exist. Thus, we first need to select all contents that need to be set on skeleton form. The time between requesting to the server and getting response back is fulfilled by the skeleton screen. When a username is entered, then the app requests the server the data it needs to receive, and then displays it to screen. We see that the app’s initial state is a waiting state, where users needs to input a username. The JavaScript of this project is very simple! Here is a graph showing the progression of the application These styles are just for providing a certain width and height to the classes in HTML so that the skeleton screen looks appealing (Better UI).Ī gain, for more styles, visit GitHub Repository of this project. Styling More Featured for Skeleton Loading We will only see the styles applied in Loading class as it is the one responsible for the skeleton effect. In case you want my design, you can visit the GitHub repository of this project and view it from there. The code in CSS of the app is quite long, hence I would suggest you to come up with your own design to implement here. This loading class is styled in CSS in such a way that it describes only the basic layout of the content in the card. The only interesting thing in this HTML is every section that need to be updated with content, has a class of loading into it. Finally, an overlay division is created to be viewed if the entered username does not exist in GitHub database. ![]() A profile info division that contains 3 paragraphs tad that houses a span tag which will later be embedded with follower, repository and following count.Ĥ. Second child is the h2 tag to have user’s name to be embedded laterģ. The first child being a division that will later wrap an image tagĢ. ![]() The another child of body element is a container that contains a division with a class of profile container containing multiple children. The body of the HTML consists of a form element with a input text and a button. The HTML contains only the layout aspects of our application. Here are some examples of skeleton screen used in many web apps like Facebook, YouTube, Discord, etc. This has been proven to be a better experience than using a traditional loading spinners, loaders or animated text. Skeleton Screens however are able to hold off the users for a longer time as they give indication of the layout in which the content will appear. Having just a simple blob or a square animating with a text saying “Loading” is very boring to look at which makes users not to stay on your application for a long time. Skeleton Screens has been around for some time lately and it is for a good reason. Despite of it however, fetching data from the browser also takes time as it is an asynchronous task, thus we some some sort of loading screen to assure the user about it. Loading data now days is done in browser or application itself, rather than the server.This mitigates the need of waiting for ages for the data to finally come back and load in user’s application. Creating a better User Experience even while your user awaits!
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |