When you open VS Code, it automatically opens the most recent project you were working on, which is convenient most of the time. Other times you will want to open a different project or start a new one. In VS Code, you will want to go to "File" and click on "Open Folder." Then you can choose the project that you want open in VS Code.
After you've worked on more projects, going to "Open Recent" will let you choose a previous project that you've worked on instead of manually clicking through "Open Folder."
Angular is a command line interface used to work with Angular applications and develop web applications.
To begin, when you first start working on your web application, anything that first appears is part of your app.module. We explain in a later section, but the app.module is like the foundation of your project and you can alter the app.module files to immediately see any changes (you should see this in your Angular lab).
If you want to add a feature to your application like a button or a search bar, you will add a component. Components, like the app.module, add information to your web application.
This is a topic that is emphasized in lecture and we would recommend asking the professor(s) more about it if you have questions.
A good explanation can be made using a bank analogy. Let's say someone walks up to a bank teller and wants to take out money. The customer gives the teller their information and the teller retrieves the money from the vault. In this scenario, the customer is like the client, the teller is like the server and the bank vault is like the database. When the client is accessing a webpage, it gives the server information about what it wants to access. The server then goes to the database to request that it returns the desired information/data. The server uses the information provided to filter the database search and returns the desired information to the client.
-
To recap:
-
Client - User clicking around on a webpage
-
Server - Webpage taking information, making requests to the server and returning the information requested by the user
-
Database - Housing of information/data which is accessed by the server
App.module
App.module is like the foundation of a web application, think of it as the brain of the project. What you are able to do in Angular is create components. A component is like a feature on a web page, an example would be the search bar on YouTube. Components are extra things that can be added to a web page to make it more useful. When we go over the app.module.ts file, you will see that each component you make must be imported and declared.
App.module consists of 6 files:
-
App-routing.module.ts
If you are adding a component that requires the user to access another page other than the main application page (which you will eventually have to do) you need to define that path here. The home page itself has a url, so a new page will need a new url/path, which you define here (It's more useful if you create the component first in the component.ts file to avoid naming errors).
-
App.component.html
This is the file that controls what text and images, go on the specified page of your web application. It also has a variety of other features that you can explore such as adding a toggle button.
HTML is a markup language used to create web pages for display in web browsers. It is the code for creating web pages, using tags and other commands that a browser reads and converts into the readable web pages that people see.
-
App.component.scss
This file controls the CSS for the html which allows visual customization for certain aspects of the web page, such as changing the color of buttons.
-
App.component.spec.ts
This file tests the methods in the app.component.ts file.
The file utilizes the methods like toBeTrue(), toBeFalse(), toBeTruthy() and toBeFalsy(). They are what they seem, they are methods used to check if the provided input is true or false.
-
App.component.ts
This file (along with all other component.ts files) are very important. Here, you can create methods that move data/information, which essentially controls the functionality of the component. Each file on the client side is written in TypeScript which is a language with its own syntax. The files for the server are written in Java which you should have some familiarity with and will be noted by ".java" in the file name.
-
App.module.ts
In this file, you must import and declare each component or it will not work. It is small, but it is necessary for the files to communicate and function.
You are going to want to see what your application looks like while you work on it so you can view any changes being made.
-
To run the server:
-
cd server (If the server is already running this command will not work and say the local host is already running, this also applies if you have the server running in another terminal window).
-
./gradlew run
-
To run the client:
-
cd client (This only applies if you aren't in the client)
-
ng serve
-
Then go to localhost:4200 (your application may experience bugs when using different web browsers, typically Google Chrome has worked the best at first) and it will show you your web application in a new web page.
IMPORTANT: When you want to close VS Code and you have run the client and server, you must hit Control+C in the terminal for both the client and server. This shuts down the client and server so it doesn't lock you out the next time you try to access it. There are fixes for this issue if you do forget to use Control+C, but hopefully you can avoid that.
-
Component.html
Files that end with component.html provide the text for a component, such as what words will go on a button (log-in, etc.). It is possible to change the characteristics of the text like making a word bold or choosing a font but this is usually best handled with CSS.
If a user is providing an email, you can make something like "User's email: (insert here)." Different users will have different emails, but the first part will remain the same. This isn't restricted to just email, any information that the users provide can be displayed if you write the right methods.
This file is also where you can add buttons on a webpage. What happens with these buttons are defined in the component.ts file. These buttons (when clicked) can bring the user to another page, so you're able to add a link to this file as a button.
-
Component.ts
This is the TypeScript file for a component and where the methods for a component are written. As mentioned before, this is where you also define variables which are crucial, because a lot of bugs will most likely result from a variable not being defined or being utilized incorrectly.
This TypeScript file is similar to a class, where it's methods are defined, and you can utilize them in other places with the defined variables. This is also where variables are initialized in the ngOnInit method. Those variables could be undefined with ngOnDestroy.
Here's what you usually find in this file:
-
Importing the necessary routes, services, etc.
-
A constructor (usually declaring the imports)
-
An @Component and export class (Component)
-
Variables (defined as string, boolean, etc.)
-
ngOnInit and ngOnDestroy
-
submitForm (optional)
-
-
Component.spec.ts
This file is used to test the methods that are written in the component.ts file. It checks to make sure that the methods are behaving how you want them to. Because the tests are local (within VS Code) they can't actually reflect your web application. So we utilize mock testing to test our methods with "fake" data that we create.
-
Mock Testing
-
Testing a component is an important part of this class and the functionality of the project (it also helps with debugging). Mock testing data is in the (nameHere).service.mock.ts file. In the component.spec.ts file, after all the imports, there is a describe method that defines the imports.
-
There is also a beforeEach method that does something before testing a method. If a beforeEach method has "async" then whatever is defined in the beforeEach will happen asynchronously from the other tests.
-
The tests start with an "it" statement telling what the method should do or what it should output. Commonly seen are toBeTruthy() and toBeFalsy() which say if something should be true or false. equals() is also another common statement in a test.
-
As mentioned before, each test looks at the file (name).service.mock.ts. This is where all the "fake" data is defined and what the tests refer to. This file is like a "fake" database of information that you are testing.
-
-
Component.scss
This is the CSS file for a component. It styles the text along with the pieces of the component itself. You can add color, borders, background images, dropdown menus, etc. This website has a lot of CSS stuff that you can quickly apply: https://www.w3schools.com/css/css_border.asp.
CSS is a standard but powerful facet for developing web applications. (This will allow you to give your application a professional setting and look for the user). If something looks clean and professional, it's bound to do well, and it gives a sense of confidence. Avoid going over the top with it and ending up with a cluttered UI, but there are enough options to make your web application stand out.
-
Creating an Object
A TypeScript file (not attached to a single component) can be used to define an object. So if you want to create an object that resembled an email, you would declare that the object "email" has a date, body/message, subject line, sent from, and sent to fields. The name for this file would then be "email.ts" So any component that utilizes this object (by importing it) can access any of the fields.
Each field has a type. Some common ones are string, boolean, etc. You also have the ability to make user defined types.
Try to think of this file as multiple people agreeing to speak in the same language.
-
Services
-
Services will be an important part of your web application. A service file has a bunch of methods that can be utilized by any component. Unlike a service file, TypeScript files for a component are specifically for that component.
-
Components that use services, have to share the same information. For example, if two different component files utilize a service, and that service has the variable "note", then "note" is defined the same in both files. To declare that a component is using a service, you need to import it.
-
-
Spec files for components also need to import services so it can be tested for a component.
-
Services also have spec files to test the methods. NOTE: Inside of these spec files, you create the data that you want the service to test.
-
Controller
Remember that the server is a way for a user to access specific information from a database. So this controller file has methods that access and change information in a database.
The controller also has a .java file which is similar to an object file like "email.ts" on the client side. It's where an object/variable is defined and it can be utilized in the methods.
After the .java file comes the Controller file, which is written in Java. As mentioned earlier, this file has methods that work within the parameters you set in the .java file. It "talks" to the database and can retrieve or change information in the database.
If you have taken Data Structures, you will notice the syntax is a little more complicated, but is still familiar enough that it's understandable.
The Controller also needs to be tested so you know the server is doing what you want it to. You will configure these tests by writing JUnit tests.
Like in the client, this test file also has @BeforeEach to declare what is instantiated before each test.
The data that you test is also something you define at the beginning of this file. You're essentially creating a mock database.When you add an object to a database, it must have the same fields as it does in the .java file. So our email object would require the fields body/message, subject, etc.
Each test should have an @Test to declare it's a test. It will also provide a "Run Test | Debug Test" option. Clicking Run Test will either give you a check mark or an X (failure). NOTE: Just because a test passes, does not always mean it does what you want.
At times a failing test can be the result of how the test itself is written but most likely it is an issue with the method. Being able to read why a test is failing, and possibly which line is causing the error, is a necessary skill in order to debug your code.
JUnit testing can be tricky and the syntax can cause headaches at times, so this is a topic we would suggest you ask your professor(s) about if you need further clarification.
-
About Databases
Remember that a database works as a bank of information/data. You are able to add, remove, or alter these entries in the database.
For this class we used MongoDB as our database. When you are working on your iterations/labs, you are able to add sample information to your database with a JSON file. To add sufficient amounts of sample data easily, you can use a JSON generator which can be found online. We have found Mockaroo.com to be the easiest to work with as the fields are easily customizable and there is a straightforward link to download the document.
To view a database in VS Code, you need to download the Azure extension. From there you should click "Attached Database Accounts." From here you can see what is in a database.
Seeding the database takes an existing JSON file and adds that to a database. Seeding the database will grab all of the current JSON data in VS Code and add it into the database.
To seed a database, you need to first cd into the database file. So open a new terminal and the command is cd database. Then ./mongoseed.bat seeds the database.
E2E (End to End) testing tests the connection between the client and the server. It tests whether or not your client to server interaction works and does what you want it to do such as adding an entry to a field or deleting an object.
The E2E files are in their own folder called e2e.
Like the components in the client, there is a .ts file and spec.ts file. You're basically writing more spec tests (like you did for components) but it doesn't test a certain component, but rather the entire application's functionality, the goal is to write tests that will replicate user scenarios.
VS Live Share is an extension on VS Code that allows you to pair program with other people. It is similar to Google Drive where multiple people can work on the same code at the same time but in this case one person is hosting the session so they will be responsible for running the client, server, and tests as well as handling commits and pushes.
This is an ideal tool if you have to work remotely, because you and your group can see in real time what is being changed. This also allows you to have an extra set of eyes to look over code which can be very helpful for finding small bugs.
To use it, you first need to download the extension along with the Live Share Whiteboard extension. When you first start or join a collaboration session, you will have to login into GitHub. Then you should have code to share with other people who can join the session
