This project was generated with Angular CLI version 18.2.11 and node v22.11.0. It is deployed at the following URL: https://ipcm27.github.io/one-hundred-cards/
desktop:
mobile:
The project demonstrates how to manage application state with NgRx in a scalable way, using best practices in Angular for component structure, error handling, and testability. It serves as a clean example of integrating NgRx into a responsive Angular application.
When a user enters the page it should see 100 cards fetched by https://jsonplaceholder.typicode.com/. Each card should have the following properties:
{
"userId": 1,
"id": 1,
"title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
"body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
},
- As the content of the square, by default, show the post title. Then,
- When clicking a square, rotate through the properties of the post one by one (on every click). For example, on the first click,
replace the title with the userId, on the next click show the id, and so on.
- When clicking any other square in the layout, any previous clicked square should also be updated back to its default state.
- Only one square at a time should show details.
- On top of the page show the id of the current active post.
- Although I am more familair with bootstrap, I choosed to use Tailwind to be more aligned to the client's technologies.
- I created two seprated components: PostPageComponent and PostCardComponent to be aligned with Angular's philosophy of modular design so it can be more scalable and reusable. This organization demonstrate the Single Responsibility Principle (SRP) been applied.
- PostCardComponent is responsible for handling each individual post. This means it only deals with the input/output of the card info and events;
- PostPageComponent manages the collection of cards (the whole page). Its main job is to handle the page-level responsibilities by communicating with the store.
- This approach encapsulates the logic related to displaying individual posts within each card component.
- The organization regarding the store: reducers, actions, selectors and effects; is reflecting the Open/Closed Principle (OCP). If I need to add a new fucntionallaty I can create a new case without having to modify the existing ones.
- The components are loosely coupled by using the Dependency Inversion Principle (DIP). For example: PostService, which is injected wherever needed rather than being instantiated directly in components.
- Facade Pattern: The NgRx Store works as a facade for managing global state. Instead of each component accessing state directly, I use actions and selectors to keep it all organized and consistent.
- Observer Pattern: With RxJS, actions and selectors are observables, so components can just “watch” for state changes and respond as needed. This setup is perfect for keeping the UI reactive and in sync with async data.
- Container-Presenter Pattern (Smart-Dumb Components): I’ve split the app into smart and dumb components:
- PostPageComponent is a smart component that handles state and communicates with the store.
- PostCardComponent is dumb, just focusing on displaying each post and handling events. This setup keeps components modular and easy to test.
- Effect-Level Error Handling: Errors are primarily handled in the Effects layer (such as with loadPostsFailure), where errors are caught and passed along to the store. This allows the app to handle issues gracefully without crashing, making it possible to display user-friendly messages instead of silent failures.
- User-Friendly Messaging: In case of an error, the application displays a clear and helpful message to the user (e.g., “Oops! Something went wrong…”). This provides immediate feedback and even suggests actions the user can take, like refreshing the page or checking back later.
1. We use JWTs a lot throughout our API. For instance, when a user logs in on our API, a JWT is issued and our web-application uses this token for every
request for authentication. Here's an example of such a token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJzb21lb25lQGV4YW1wbGUubmV0IiwiYWRtaW4iOmZhbHNlLCJ2YWxpZF91bnRpbCI6IldlZCBEZWM
gMzEgMjM6NTk6NTkgQ0VTVCAxOTY5In0.4bl2puoaRetNjO1GsweKOnnQsYgwNa9bQIC-WQZkuNo
Why is it (or isn't it) safe to use this?
JWT Auth is vastly used on the web. It provides a way the server knows it's client by provifing him a token. JWTs have three main components: a header, payload, and signature. The signature helps verify the authenticity of the token and that its contents haven't been tampered with.
Why is safe ?
- Are digitally signed (using algorithms like HS256 or RS256), meaning the server can verify if the token has been changed.
- Expire after a set period, reducing the risk if a token is intercepted.
- Can carry claims (user data or roles) that the application can validate without querying a database each time.
Why could not be totally safe ?
- JWTs store user data (claims) directly in the token payload, which can expose sensitive information if not encrypted.
- If a JWT is intercepted (say, in an unsecured network connection or by a compromised device), the attacker can impersonate the user until the token expires.
2. In our web-application, messages sent from one user to another, can contain HTML, which poses some security risks. Describe two attack vectors bad actors might try to abuse? And how would you mitigate these vectors?
- XCSS: A bad intended developer could intercept the message and embed malicious JavaScript in HTML content.
- Phising: A bad intended person could insert an html in the message that redirect to an outside link and that user would be in danger.
3. Explain the difference between mutable and immutable objects.
As the name already says, mutable objects can be modified after creation, and immutable objects, on the other hand, can't.
- What is an example of an immutable object in JavaScript? Primtive data types. When we edit a string it creates a new one.
- What are the pros and cons of immutability?
- pros: it makes the code cleanner and easier to trace where the change come, avoiding side effects.
- cons: it makes the code bigger and increased memory Usage.
- How can you achieve immutability in your own code?
One way to keep objects immutable is by creating a modified copy instead of altering the original object. For example, if you have a function that takes a car object as a parameter, instead of directly modifying car and returning it, you can create a new variable (like carModified) that copies the properties of car, make any changes to carModified, and then return this new object. This way, the original car object remains unchanged. Another one would be using const insted of let.
4. If you would have to speed up the loading of a web-application, how would you do that? (no need to actually do it, just describe the steps you would take)
- I could enable Lazy Loading for Modules.
- I would review my application and see if the infos that are been request are actually necessary.
- I would consider using cache systems to avoid calling the server many times.
- I could implement SSR (server side rendeinrg) if it wouldn't compromise the server.
- I could compress images and assets to optmize if that didn't compromise the quality of the web application.
Clone the project then use npm instal. I'm using node v22.11.0.
Run ng serve for a dev server. Navigate to http://localhost:4200/. The application will automatically reload if you change any of the source files.
Run ng build to build the project. The build artifacts will be stored in the dist/ directory.
The deploy was done at gitbuh pages npx angular-cli-ghpages --dir=dist/one-hundred-cards
Run ng test to execute the unit tests via Karma.
Run ng e2e to execute the end-to-end tests via a platform of your choice. To use this command, you need to first add a package that implements end-to-end testing capabilities.