Webdevelop PRO

webdeveloppro

213 Stories To Learn About Guide

306 Stories To Learn About Webdev

249 Stories To Learn About Web Development

338 Stories To Learn About Frontend

302 Stories To Learn About Front End Development

Let's learn about via these 62 free stories. They are ordered by most time reading created on HackerNoon. Visit the to find the most read stories about any technology. Documentation /Learn Repo 1. Tips For Winning a Proposal For Software Engineers Chances are if you're doing freelancing sooner or later you'll come across a need to write some kind of proposal to your potential customer. 2. The Red Death of Flutter Explanation of how Google's Flutter UI startup app was debugged and made to work again and connect with it's central Firebase Database through hours of work. 3. A Guide to Using Data Classes in Python In "C" Language, you have structs. With the help of structs, we can define the return data type. You can do the same using classes in python. 4. How to Make Documentation Easier to Read Let’s see how you can develop the skill of reading documentation! Most importantly, start by getting your answers from the documentation as you struggle. 5. Introduction to Great Expectations, an Open Source Data Science Tool This is the first completed webinar of our “Great Expectations 101” series. The goal of this webinar is to show you what it takes to deploy and run Great Expectations successfully. 6. Trust Signals in Open Source Projects Polish the trust signals of your open source project to increase your user base and grow your community. 7. Tips For Documenting Your Code Some will tell you that good code is self-documenting. In other words, if you write clear code then you won’t need comments. 8. Re: "Nerds Don’t Respond to Marketing" These are 13 --lightly edited-- response comments on how marketing to nerds requires a different approach. 9. An Easy README Makeover In 3 Simple Steps Oh yeah! We’re giving your README a makeover! 10. Autogenerate Your GraphQL Documentation With Magidoc Learn how to autogenerate GraphQL documentation with Magidoc. 11. Online Technical Documentation Is Almost Dead We waste so much time and energy searching for answers because online technical resources are bloated, lack simple examples, rarely improved and have bad UI/UX. 12. Why Programmers Struggle To Write Good Documentation For a programmer, proper documentation is a must-have. Its presence keeps track of the development process and later assists during the maintenance period. Successful documentation will make information accessible while providing limited users with entry points. It further helps new users learn quickly by simplifying the product and cut support costs as well. 13. The Code Is the Documentation; a Paradox That Rings True The first time I heard someone say: “the code is the documentation”, I thought it sounded completely wrong, like a lazy excuse for not producing documentation. 14. Devs - Documentation IS Important Should you write software documentation? This article covers best practices of writing docs in a team or as a solo engineer. 15. Auto-generation of Documentation for Event-driven Architecture Auto-generation of documentation for Event-driven architecture 16. How We Built Our Software Documentation On Docusaurus To cover our bases, we needed to improve and expand our documentation and this time, we wanted to make it scalable with Docusaurus. 17. Create, Edit and Manage Screenshots with Snagit 2021 How does the new version of Snagit help you create, edit, and manage screenshots, and is it worth upgrading from what you currently use? 18. Top Tips and Tricks For When You're Working with PDF Files Are you looking for PDF tips to ease your daily work? Read this article with all tips PDF users might need to achieve the results they want. 19. Use Comments to Unit Test Your Code [A How-To Guide] At Supabase we love writing as little code as possible, so we decided to combine our unit tests with same JSDoc comments that power VSCode's IntelliSense. 20. Rapid Way to Publish Python Docs With Free Hosting and Domain How to create a documentation website based on markdowns and also publish it on GitLab Pages. And as a bonus, how to get a free domain like my-project.py.wiki. 21. 'One of the most pervasive failures (of FTX) is the absence of lasting records of decision-making' FTX + SBF Chapter 11 Court Filing by John J. Ray III, Nov 17, 2022 is part of HackerNoon’s Legal PDF Series. Part 15/20: Information & Retention of Documents 22. Doc-as-Code: Managing Content is Easy When it’s Distributed Few months back, I got a call from GitLab for a technical writer position.
One of the question was about treating document as a code and what’s my
view on that. The question was about treating document as part of a
continuous integration and continuous deployment system. That question
came at the time when I wasn’t treating doc as code and ironically, I now have a perspective. 23. Beware of Documentation Management. A Techlead's Hell Loop. Software documentation can improve developer productivity a lot, but it has to be updated automatically and linked with the codebase which can be time consuming 24. Documenting GraphQL APIs The main reason for writing API documentation is to make your API understandable. For GraphQL there are many options. Both interactive and static documentation. 25. OpenAPI Specification v. 3+ Introduction Mental Checklist 26. Save Yourself the Headaches and Document Agreements the Right Way Agreements are an essential part of software development. They lower development costs and make developers' lives easier. But there is a problem.. 27. 6 Ways Digital Document Management Will Empower Your Business Where does your company fit with today’s paperless trend? If you’re yet to harness a fully digital business, you’re not alone. Research proves that organizations still struggle to reduce paper consumption. In fact, throughout 2023 and 2024, the paper output in the USA is expected to grow, which shows that workplace digitization is proceeding pretty slow. 28. Dealing with a Large Undocumented Codebase I was recently asked to answer the somewhat vague question, “How do you interact with a large undocumented code base?” 29. Demystifying Tech Debt: An Overview of the 4 Types with Actionable Fixes Learn how to manage technical debt in your codebase with this guide on the 4 types of tech debt, with examples. We'll look at how to fix each type of tech debt. 30. Why is the Documentation of Tech Products So Hard to Use? (in the User’s Point of View) Documenting tech products is a key part of making a project sustainable in the long term. Despite that, properly documenting them is incredibly difficult. 31. Software Development Knowledge Sharing Methods Are Broken: Here’s Why Knowledge sharing for engineerings team and software developers is broken. Consuming knowledge at the right time is the key to success. 32. How To Improve Your Software Documentation by Connecting Gitlab with Mkdocs Producing documentation may be painful and need a lot of time to write and operate. In this story, i will share with you, my way of generating docs using the devops approach. To make life easier, we will explore the art of automation 😃. 33. Digital Transformation in Banks – Role of Document Automation Document Automation is the perfect start to digital transformation. It offers a low-risk investment with immediate returns for banks. 34. The Power of Whitepapers: Ensuring Quality Control in the Crypto Industry One of the most pragmatic ways to implement quality control in crypto decision-making process is monitoring a project’s attention to detail in its whitepaper. 35. Setting Up Docs For An Open Source Project Doesn't Have To Be Hard This article describes how we set up docs for our open source project Saasform. Docs are part of the source code, so they're browsable and easy to maintain. Mor 36. Building a ChatGPT-Powered Markdown Documentation Learn to build markdown documentation with Chatgpt and the OpenAI API 37. How to Name Things Properly Perhaps it is not news to everyone that there are two hard things in Computer Science. 38. Why Does it Often Take Nearly a Month to Ship a Few Lines of Code? Ever wondered why it takes nearly a month to ship out a few lines of code change to the star and reliable customers of your company? When the changes made are formally aligned with the product, marketing and application managers, what stops it from being shipped immediately? Why do managers quote timelines for a maintenance release that seems so "unrealistic" to you? These were the thoughts that were going through my mind during my first few months of writing production-quality code. 39. How to Publish a Book with GitBook CLI and GitHub Pages in 7 Minutes Publishing a book or documentation online has never been easier than it is today. 40. How To Define The Good Documentation Skills When comparing products, you want to decide on their usefulness. Yet, we often forget to evaluate the project's documentation 41. Building a Strong Portfolio in the Early Stages of a Startup: Tips and Strategies A startup team may fail to deliver a product but should not fail to deliver a portfolio of value. 42. 5 reasons to ditch the paper and start document automation Document automation is here to stay. Your company needs to change today. Here's five reasons why. You'll make your clients happier, and your employees happier. 43. ...So I Ended up Making DocBrowser - An HTML Template for Documentation Recently I've been working on a couple of projects that required on-line documentation.  After looking at several existing templates and not finding any that were quite right for what was needed, I decided to take the time to build one. 44. Exercises on Dependency Injection in  ASP.NET: Introduction In this post, we will do some exercises to go over the basics of DI (Dependency Injection) in ASP.NET. 45. How To Generate API Blueprint using SwagGo Generating API blueprint REST API Golang using SwagGo tools 46. Remote Work: GitLab CTO Eric Johnson Shares 10 Tips to Make the Most of the New Normal Eric Johnson, the CTO of GitLab (a FULLY REMOTE company with 1500 employees) shares his tips on how to manage a fully remote team async across timezones. 47. Why Git Is A Great Documentation Management Tool Sometimes not only documentation but also the process of working on it may be critical. For example, in the case of projects, the lion’s share of the work is related to preparing documentation, and the wrong process may lead to errors and even loss of information, and, consequently, loss of time and benefits. But even if this topic is not central to your work, the right process can still improve the quality of the document and save you time. 48. Creating Beautiful Documentation Website For Your JavaScript Project Nowadays, as a webdeveloper, you rarely build anything from scratch: your daily job mostly consists of integrating various Javascript libraries together. If you are building a web app you are most likely going to use some framework like React, Vue or Angular for your front-end. To transmit and manage the data you will be using Redux or GraphQL. For the backend, there will be Express and probably Loopback. Then you need to cover everything with tests, so Jest, Mocha or Jasmine must be present too. Finally, there will be UI frameworks like Bootstrap and maybe some charting tools. I have already counted at least 7 core libraries and all of these are in a single project! And what about underlying technologies like Javascript itself, Node.js and, probably, Typescript? Well, that’s a lot! 49. Code as Documentation and Assessment Documenting IT networking lab procedures in code rather than word-processor documents enables more authentic, equitable and consistent assessment. 50. How to Solve Engineering Problems Using Scientific Method On every new software product, feature or project you develop you are bound to come across challenges that don’t have a clear answer at first. 51. How to Lose Developers and Alienate Users: 5 Ways Not to Write Docs I recently joined Jina AI, a startup focusing on neural search. One of the things that got me interested was their documentation — while not perfect, it’s straightforward, practical and easy-to-read. I wish that were just as true of every tech product out there. 52. My Takeaways After Attending Google Summer of Code 2019 This summer, my proposal got selected by Open Source Robotics Foundation for Google Summer of Code 2019. It was an awesome learning experience! 53. How to Initiate a Software Requirements Specification How many times have you felt that it would have been better to contemplate the project requirements? How many times did you feel like including that “one” particular feature/function could have saved it from failure? Hold on to the thought right there! Do you think a System Requirements Specification could have played a pivotal role in success? 54. Open Source Series: Documentation or answering the what and how questions 55. Part 1: Why Software Requirements In The Real World Are Hard This is the first in a series of posts about my experiences developing software in healthcare with my team over the last few years. For most of that time we’ve worked in eye care, with doctors and patients in major centres in Europe, North America and Australia, as well as with global life science companies, on projects aimed at improving care delivery and patient outcomes. 56. We Need to Talk About DX (Developer Experience) I want all involved in development to think about other users. Not about those who use your application to solve their problems. But those who extend your app, run it in production and integrate with other systems. About developers, operations, SREs and many others who make your business running. Those behind the curtains. I want you to think about the Developers Experience (DX). 57. How to Write API Documentation the Right Way API documentation is a critical part of any application's success. 58. 5 Software Documentation Tools That Make Managing Technical Documentation Easier Software documentation is an important step in the process of software development. These are the 5 tools that make the cut when it comes to functionality. 59. Why NPM and Yarn f*cking suck Opinion piece: What we can learn about documentation and logging 60. How I Use Notion to Manage My Relationship A list of reasons why you should try documenting your relationship on Notion 61. Readable Legal Documents Are No Longer a "Nice-to-Have" By writing your company’s privacy policy in a clear and structured way, you influence how privacy policies are written and designed in huge organizations. 62. How to Describe Your Technical Issue to Get Quick and Effective Help Documenting the issue before you ask for help will make everything so much more efficient. Thank you for checking out the 62 most read stories about Documentation on HackerNoon. to find the most read stories about any technology. Visit the /Learn Repo

62 Stories To Learn About Documentation

A Look at the Trends in Developer Jobs: A Meta Analysis of Stack Overflow Surveys

Una mirada a las tendencias en los trabajos de desarrollador: un metaanálisis de las encuestas de desbordamiento de pila

Un regard sur les tendances des emplois de développeur : une méta-analyse des enquêtes sur les débordements de pile

डेवलपर नौकरियों में रुझानों पर एक नज़र: स्टैक ओवरफ़्लो सर्वेक्षणों का एक मेटा विश्लेषण

開発者の仕事の傾向を見る: スタック オーバーフロー調査のメタ分析

Uma olhada nas tendências em trabalhos de desenvolvedor: uma meta-análise de pesquisas de estouro de pilha

Xem xét xu hướng công việc của nhà phát triển: Phân tích tổng thể về Khảo sát tràn ngăn xếp

看看开发人员工作的趋势：堆栈溢出调查的元分析

HackerNoon strives to provide developers with the best platform to publish their work, share their stories, and learn through their peers and like-minded individuals working in similar industries. To help provide devs with something to strive for and a fun topic to write about, we partnered with Wix to host the Velo Writing Contest. Each month, we’re giving away up to $4,250 in prize money to the best articles showcasing the potential of Velo and Velo APIs to seamlessly build web pages and web apps. The Selection Criteria For the first round, we selected the 5 stories published with the tag on HackerNoon that received the most views. #build-velo-web-app From those 5 stories, HackerNoon editors voted on which stories were best based on the scale of the Velo project showcased in the article and the quality of the writing and presentation of the project throughout the story. It's time to present our favorite stories, but first, let’s look at all the nominees: 1. - by Building a Website for a Dental Clinic Using Wix and Velo @webdentist 2. - by 3. - by How to Make an Online Timer via Velo's GUI or JavaScript Editor @amateurweb Building a Wedding Website in 5 Minutes from Scratch @webdeveloper123 4. - by Building Advanced Forms and Custom Interactions with Velo: A How-To Guide @ritwik 5. - by How to Add a Blog to Your Wix Website and Edit JavaScript via Velo @augustkim The Voting Process We used Polly (a slack app) to build the voting panel and true to the spirit of decentralization, everybody on our Editors Slack channel got to pick their three favorite stories each. We all had 3 days to pick our favorites. The Winners! came out on top as the clear winner. Building Advanced Forms and Custom Interactions with Velo: A How-To Guide wins $2000! Ritwik "There comes a time when you require something more than just a simple flow of questions. Maybe you want custom logic that affects a user's interaction with your form or you want the form to be multilingual by design or both." came in at second place! Building a Website for a Dental Clinic Using Wix and Velo wins $1000! Forest William “Let’s test Velo’s might by building a professional website for a dental clinic. This tutorial will guide you through the essential steps necessary to give the company a digital presence.” What’s Next? A hearty congratulation to all the winners and worthy contenders! Winners will be contacted via email with instructions on how to claim their prize. For those of you who couldn't win this time or have yet to participate, here’s how to join in on the fun: The Velo Writing Contest is still ongoing. on HackerNoon. Create an account Check out the . Velo Writing Contest rules Pen your story and submit it with #build-velo-web-app as one of the tags. Share your story on your social media channels to reach a wider audience and boost your chances of winning. If you need some inspiration, . check out the current submissions With that, we're calling it a wrap. Until next time!

The Velo Writing Contest: Round 1 Results Announced!

Nowadays, as a webdeveloper, you rarely build anything from scratch: your daily job mostly consists of integrating various Javascript libraries together. If you are building a web app you are most likely going to use some framework like React, Vue or Angular for your front-end. To transmit and manage the data you will be using Redux or GraphQL. For the backend, there will be Express and probably Loopback. Then you need to cover everything with tests, so Jest, Mocha or Jasmine must be present too. Finally, there will be UI frameworks like Bootstrap and maybe some charting tools. I have already counted at least 7 core libraries and all of these are in a single project! And what about underlying technologies like Javascript itself, Node.js and, probably, Typescript? Well, that’s a lot! So how do you learn all of these tools? Of course there is a such thing as a documentation. Why documentation is important? There are two ways you can relate to documentation: you can either write or read one. Sometimes you are on both sides, but in most cases you are consuming a creation of other developers. You would not use any of the mentioned libraries, unless they were well documented, would you? Which brings us to the first point: People will not even consider your project unless it is well-documented This may seem obvious but, if your code is not documented, then the only way to learn what it does is to reverse engineer it. Would you do that yourself? Let’s consider the extreme opposite and imagine if React, for example, had no documentation. Then there would be only few geeks to try this new tool from Facebook, since it would require browsing over the source code to understand what it does and how to use it. Of course there will be no businesses or enterprises using a non-documented library. What kind of CEO or CTO would want to risk their company’s resources on a technology that has unpredictable onboarding time? Moreover, it would be hard for Facebook’s engineers themselves to support and maintain the codebase, which makes a second point: You will not be able to understand your code in 6 months I bet you know the feeling when you look at the code that you have written a few months or years ago and can not understand a single line. It is even hard to admit the code was your creation. Sounds familiar? The code may even look like it was written by someone much less experienced and may seem silly, but still you are unable to explain what is going on there. Why did you write this? At that moment an intense feeling of regret will creep in and you will start to realize the best moment to write a documentation was when you wrote the code, i.e. 6 months ago. Now, instead of reading the docs, you will have to read the code, and the code does not answer the question “why” it was written and does not explain itself. So the main purpose of documentation is to explain why you wrote this piece of software, including for yourself in the future. Documentation is a love letter that you write to your future self. – Damian Conway Documentation makes the code better You will have to think a lot about the design of your code when documenting it. Since you have to expose the whole structure of the code to the public, you will think twice about the way you built your project. Are there any parts to be refactored? Is there a way to implement some functionalities better or completely reorganize the code? So documentation process itself makes the code better. What to write? After it became clear how important documentation is, it seems that we can start creating one. However, before proceeding, I would recommend to stop for a while and do a step zero by clearly defining your target audience and understanding the value your project generates. Define your audience This one seems obvious but is often forgotten. It is better to clearly formalize who you are writing for. Who are your users? Are they mostly developers or designers? Experienced or fresh? Do they use your project in a large or small team? Etc, etc. Answering these questions will help you define an imaginary persona, which represents most of your users. Keeping this imaginary persona in mind will help you a lot, so the process of writing docs will look more like a dialog between you two. What problem your project solves The first thing to add to your document is a clear definition of what is the name of the project and what problem it solves. It is better to have one or two sentences. People are going to be visiting your page from many sources and, hence, have different perspectives. That’s why you have to be very precise and avoid vague descriptions. Simply state what your Javascript project is about, who it is for and what problem it solves. As an example of proper title and description, you can check out . Sing App React Admin Template documentation Quick start and installation steps Most people do not like to wait. So do your users. Let them launch and try your project as fast as you can. Prepare a simple short list of steps needed to setup the project and put it on top of documentation front page. Usually it may be a list of commands required to setup an environment and start the application. If it’s possible, it will be great to simply copy-paste these commands and have the entire application or library launched. Take a look at as an example: Rails Admin documentation A list of steps needed to setup the library is clear and easy to execute, which makes the whole project more attractive to use. Hopefully your users will be able to setup and launch everything, so now it is time to go a little bit deeper. Components and features documentation It is most likely that quick starting the project will not be the only option available to interact with it. There will be other parts, modules, components, features, classes, etc. You name it. E.g. pieces of your software that require separate documentation and provide an API to interact with it in some way. The first thing to do is to list all of these components and make a table of contents based on it with links following to the relevant pages. For every single piece of your documentation it is better to apply the same principle you apply to writing project description: name the component, describe what it is used for, what is the installation process, if there is one. What are the API methods and parameters, if so? Try to put yourself in a place of this imaginary persona you described earlier and imagine what would be the questions and difficulties integrating this particular component. Help them use it and leave no feature undocumented! A list of steps needed to setup the library is clear and easy to execute, which makes the whole project more attractive to use. Hopefully your users will be able to setup and launch everything, so now it is time to go a little bit deeper. is a great example of structuring docs. You can see the menu of all available documentation parts on the left side and interact with particular component in the middle of the page. Firebase documentation License and contribution instructions There must be something that guides relations between your project and its users. You have to decide under what conditions your software is distributed and can be used. There are lots of standard licenses available around the web, so it is up to you to pick the right one for your project. The most popular ones are: BSD, MIT, Apache GNU licenses. They are open source, so keep that in mind. Proprietary licenses vary a lot from project to project, so this can be a separate topic. If your project is open source then you are expecting people to contribute. Hence it will be very helpful for them to have some sort of guidance from you. Let them know where they can report issues, ask questions, what are the restrictions or prior assumption before contributing, where they can find issues, etc. Otherwise you are about to lose a great amount of thankful supporters and maintainers. Tips on writing documentation We will not be able to predict all the use cases and the way users will use your documentation. In general it is a great principle to keep imagining yourself as your user and organize everything based on this point of view. However, here is a short list of general tips every project documentation must follow: People will simply copy and paste your code. Keep this in mind and make sure to double check this yourself by executing it. Avoid placing some invisible characters to code examples. It is even better to use and tags to embed code blocks. code blockquote Keep your documentation updated. Every change in code must be followed by a relevant change in documentation. Otherwise documentation soon becomes outdated, which is equal to the absence of documentation. Code comments are a part of documentation. This is the last and very important one. If your project is open source, users are going to be reading through your code, hence inline comments will help them a lot. Furthermore, there are tools like that generate documentation based on code comments! So you do not have to write anything in a separate file. Simply feed this tool with your codebase and, voila, you have the documentation. JSDoc Tools to speed up the process Why would you want to write and create everything from scratch and by yourself if there are so many documentation tools available? Nowadays generating documentation, especially if you produce high-quality code with inline comments, is a matter of running a single command. So let’s overview documentation tools available in 2019. JSDoc JSDoc is the most popular Javascript documentation generator. All you need to do is to simply run jsdoc command with a filename as an argument. That is it. It will generate HTML file with documentation that is ready to use. The website is . https://github.com/jsdoc/jsdoc Docusaurus Docusaurus is a more complex tool that allows you to generate entire documentation website based on markdown files with documentation contents. It is based on React and supports versioning, so you can easily maintain different versions of the documentation generated in the past. Other great benefits are embedded search and multi language support, which is crucial for popular repositories. The website is . https://docusaurus.io/ apiDoc apiDoc creates a documentation from API annotations in your source code. It is a great tool to generate a documentation for a project that has and exposes lots of API methods. It allows to customize everything a lot, e.g. specify parameters, error codes, response samples, etc. The website is http://apidocjs.com/ Great examples of JavaScript project documentation When creating something new it is good to have some sort of example, something you can refer to. So here is the list of various projects you may get your inspiration from. All of them are great, so pick one you like the most. Firebase React Admin (a documentation to one of our own projects. We invested around 250 hours composing these docs); Template Bugsnag Ruby on Rails guides Cat Boost Summary I hope that you found this article useful and it will help you a lot when creating documentation for your javascript project. Googling the Internet tells that documentation is a key to success in any Javascript project, and I strongly agree with this rule. Documentation is sort of a facade that people face and resort to when using your project. So always keep it updated and put yourself in place of your users! Text source: - React, Angular, Vue, Bootstrap & React Native templates and themes. https://flatlogic.com The link to the original article: Writing Documentation For Your JavaScript Project

Creating Beautiful Documentation Website For Your JavaScript Project

In this post, I want to show how you can build the front and back end of a website using NodeJS for the back end. We’ll use node to create endpoints, and set up a database in JSON format. Then, we’ll create a front end application using React that will post to the database, and also fetch data from it. For this example, I’ll be making a guestbook, where users can submit their names and leave messages. Because users won’t need to log in, or retrieve any data, I won’t need to store anything in a session. Here’s the way this will likely work: Basically, we will have this all one one page, with a form for submitting a message, alongside the actual guestbook. To make this work we’’ll start by creating the endpoints for our POST and GET requests. We’ll set up our database, deploy it, so that we can create a React app, and pull data from the online API. Here’s the order in which I like to do things. You may prefer to work differently. This process makes sense to me, because each step builds on the step before it. During this tutorial, I’ll go through each step in more detail. To see how the finished project could work, here’s a link to my project: http://ethan.jarrell.webdeveloper.surge.sh/GuestBook STEP 1 - Our database collection will contain 2 items: The name of the user The message the user writes If you haven’t already done so, go ahead and install MongoDB, and get it running on port 27017. Then, on the command line, we’ll create the database. We’ll call our database signatures. And the collection, guest_signatures. > Show dbs> Use signaturesswitched to db signatures> show collections> db.createCollection(guest_signatures) Now that we have that set up, we can switch to the text editor, and create the models for the database. STEP 2 - Use the command line to start a new express app. Make the new directory, and then use npm init to create the app. This will automatically create your pkg.JSON file. Since this will be a very basic app, we’ll only need 2 other files in our express app. One for our routes. I like to include all my dependencies in this file as well. Then our second fill will be for our models/schema. We’ll tackle the model file first. It should look something like this: const mongoose = require('mongoose'); let Schema = mongoose.Schema; const signatureSchema = new Schema({guestSignature: {type: mongoose.Schema.Types.Mixed,required: true,},message: {type: mongoose.Schema.Types.Mixed,required: true,},}) const Signature = mongoose.model('Signature', signatureSchema); module.exports = Signature; STEP 3 - Before we create our endpoints here, let’s go ahead an list our dependencies at the top of our file. We don’t need too many. //== =// LIST DEPENDENCIES const express = require('express');const parseurl = require('parseurl');const bodyParser = require('body-parser');const path = require('path');const expressValidator = require('express-validator');const mongoose = require('mongoose');const Signature = require('./models/signature.js')const app = express();const url = 'mongodb://localhost:27017/signatures'; //=========================// You don’t necessarily need to connect with mongoose, so feel free to use MongoClient, if you prefer that. We’re also using the Signature schema that we just created in the previous step. Now, let’s create our endpoints. We only have one model, and we’re only going to read and write to it for now, so we’re only going to have 2 endpoints. Our root directory “/”, where we’ll redirect to our API Our api, we’ll call “/api/signatures, where we’ll read and write to. At our API endpoint, we’ll have a GET and a POST. We’ll reference our models, using the find() and create() methods for GET and POST respectively. And our response will need to be in JSON format, so that we can easily access the data there from React later on. Here’s how those endpoints might look: //== =// ROOT DIRECTORY app.get('/', function(req, res) {res.json('you did it');}); //==========================// //== =// GET ALL SIGNATURES app.get('/api/signatures', function(req, res) {Signature.find({}).then(eachOne => {res.json(eachOne);})}) //==========================// //== =// POST NEW SIGNATURE app.post('/api/signatures', function(req, res) {Signature.create({guestSignature: req.body.SignatureOfGuest,message: req.body.MessageofGuest,}).then(signature => {res.json(signature)});}); //==========================// The only thing I didn’t really mention was the req.body.SignatureOfGuest and req.body.MessageofGuest. Everything else in this section refers to something we’ve already created, like our database, collections and models. This refers to the name of the field that we’ll use in our React App, Our input will have to use the names SignatureOfGuest and MessageofGuest, so we’ll need to remember that. STEP 4 - Now, we’ll want to connect to our local database from out text editor. If you remember, we had this constant in our list: const url = 'mongodb://localhost:27017/signatures'; We’ll write a function using this constant to connect to our local database. //== =// MONGOOSE CONNECT mongoose.connect(url, function (err, db) {if (err) {console.log('Unable to connect to the mongoDB server. Error:', err);} else {console.log('Connection established to', url);}}); //==========================// In order to make sure everything is working properly, we’ll also need to add an app.listen at the end of our file. At this point, it’s a good idea to pause, and make sure the endpoints and local connection works. You can do that by using Postman to make GET and POST requests. If the endpoints or connections don’t work, you should be able to diagnose the problem here based on the error messages you receive. If everything is working, it should allow you to appropriately read and write to the database. Once everything is working, it’s time to set up our account on Heroku and Mlab. STEP 5- Sign up for a Heroku account . And create an mLab account . here here STEP 6 - After creating your mLab account, click on the Create New button and select a Single node sandbox. There are paid options as well, but the sandbox has plenty of space for getting started. Give your database a name. Since my local database is signatures, I’m using the same name for my mLab database. Now that you have your database created, you can start a new collection from here. You will also need to add a User or Users who can access your database. Without doing this step, and adding yourself as a User with access, authentication will always fail when you try to deploy it. Now your database is running on mLab. When you click on the database, you should see some information at the top, telling you how to integrate the connection. It should look something like this: mongodb://<dbuser>:<dbpassword> 9234.mlab.com:9234/signatures @ds7 The actual url of the database will just have the username and password replaced with your username and password. Now let’s head back to our text editor. We currently have the database running locally at this location: const url = 'mongodb://localhost:27017/signatures'; To change it, so that we are connected to mLab, simply update the url variable with the information from mLab. It should look something like this: const url = 'mongodb://username:password@ds79234.mlab.com:9234/signatures'; However, you’ll likely be putting this on github, or another public place. You don’t want your mlab username and password in a public sphere where anyone can see it. To fix that, we’ll set an environment variable on the command line, and then update our url variable one more time in the text editor. On the command line, use this command: export MONGOLAB_URI="mongodb://username:password@ds79234.mlab.com:9234/signatures'; Of course, replacing it with your own username, password, numbers and database name. Now, back in our text editor, we will change our url variable to the following: const url = process.env.MONGOLAB_URI; We’ll also want to change our app.listen to reflect the new port. It could look like this: app.listen(process.env.PORT || 3000);console.log('starting applicaiton.  Good job!'); This way, it will try to run from mongolab, but if it can’t make the connection, it will still listen on port 3000 by default. This will also allow you to run the app locally or from mlab, in case you want to test changes on the local version. The final step in making the connection is deploying your code to your Heroku App. to do this, you can use the following code from the command line: heroku config:set MONGOLAB_URI=mongodb://username:password@ds79234.mlab.com:9234/signatures Your app should be successfully deployed on heroku, and you can open it from there now. If you are getting errors, double check to make sure it’s running locally. If so, then it’s probably an error along the way in the connection. In these last two steps, there’s quite a bit of repetitive code. I’m going to outline the high level code here. STEP 7 - Use ‘create-react-app’ from the command line to create a new react app. STEP 8 - Now, we’ll want to create a form, to allow for user input. Here’s how we do that. In a new component, we’ll create a new class. class GuestBook extends Component 2. We’ll use a constructor and super method to pass props down. constructor(props) {super(props); 3. Use the this keyword to handle the name and message of guest, and bind it to (this). this.handleSignatureOfGuest = this.handleSignatureOfGuest.bind(this);this.handleMessageofGuest = this.handleMessageofGuest.bind(this); 4. Set the state of the name and message of guest to an empty string. this.state = {SignatureOfGuest: "",MessageofGuest: "",}; 5. Listen for an event on the state of both the name and message input. handleSignatureOfGuest(event) {this.setState({ SignatureOfGuest: event.target.value });}handleMessageofGuest(event) {this.setState({ MessageofGuest: event.target.value });} 6. Create a function that changes the name and message to the value of the target input. addToGuestBook = event => {event.preventDefault();this.setState({SignatureOfGuest: event.target.value,MessageofGuest: event.target.value,}); 7. I’m now using axios to post the input data to our database, which is on heroku. axios.post('< , {SignatureOfGuest: this.state.SignatureOfGuest,MessageofGuest: this.state.MessageofGuest,}).then(response => {console.log(response, 'Signature added!');}).catch(err => {console.log(err, 'Signature not added, try again');}); your-heroku-url here>' 8. Then I’m resetting the state of the input to an empty string. this.setState({SignatureOfGuest: "",MessageofGuest: "",});}; 9. Finally, we’ll make a render method, and return our page with the input fields. Inside the input of each field, we’ll give it an onChange, name, and value. the onChange will be set to the.handlemessage or this.handlename, for each field. The name of each field will be set to what we called it in our node app. The value will use state, and we’ll set that to this.state.message, and this.state.name. <inputonChange={this.handleSignatureOfGuest}name="SignatureOfGuest"className="NameinputForm"value={this.state.SignatureOfGuest}placeholder="Enter your name"/><textareaonChange={this.handleMessageofGuest}name="MessageofGuest"className="MessageinputForm"value={this.state.MessageofGuest}placeholder="Type a message"/> 10. Then we’ll add a submit button, where we call the function from earlier. <buttonclassName="submitbuttonguestbook"type="submit"onClick={this.addToGuestBook}>Submit to Guestbook<i className="GuestBookButton2" aria-hidden="true" /></button> STEP 9- Now we’ll make another component where we’ll render the data that’s being stored in our database. Then we can export that component, and put it on our guestbook page. Inside this component we’ll do the following: In a new component, we’ll create a new class. class GuestNames extends Component { 2. We’ll use a constructor and super method to pass props down. constructor(props) {super(props); 3. Use this.state to set the state of our guestbook messages to an empty string. this.state = {messages: "",}; 4. Use a componentDidMount lifecycle method componentDidMount() { 5. Inside that method we’ll use fetch and the url of our heroku api to fetch the information from the database. fetch('<your-heroku-url-goes-here> ).then(results => {return results.json(); ' 6. We’ll map over the data, and return the data we want. data.map((msg) => {return(<div key={msg.results}><h3 className="h3msg">{msg.message}</h3> <h2 className="h2sig">-{msg.guestSignature}</h2></div> 7. Now we’ll use this.setState to set the state of the messages to the new state using the data we just fetched. this.setState({messages: messages}); 8. Now we’ll create render mehod. render() { 9. Inside the render method, we’ll create JSX elements to render our data inside the component. I’m using this.state.messages inside an <h6> tag. return ( <div className="guestdataContainer"><h6>Guestbook Messages</h6>{this.state.messages}</div> 10. Finally, we’ll export the component, so we can use it on other pages. export default GuestNames; Again, if you have any questions feel free to reach out. Thanks!

How To Combine a NodeJS Back End with a ReactJS Front End App.

Stories, News & Mentions about WEBDEVELOPPRO

Webdeveloppro’s Stories on HackerNoon