Angular provides two types of forms, template-driven and reactive. As we want to do some form validation and provide nice date pickers on the form, reactive forms were chosen.
The form is quite simple at the moment will will get a bit more complicate as I add more complex use cases. The form uses the ngx-boostrap datepicker component which includes a date range selector.
Form Validation
Angular provides some validators out of the box such as 'required'. For more complex validations, custom validators can be written and hooked in. This form uses a mixture of both types.
Once a trip has been added, it can now be 'viewed'. This is a very early version of what will become the 'hub' of the system, where trip participants can organise their trip. It's just a read-only view at the moment but this will change as the trip planning use-cases are added.
A bug with trip dates
In this sprint I needed to investigate a bug with the dates being displayed. If I entered 11/06/2020 to 12/06/2020, when I loaded the trip back, it was showing as 10/06/2020 to 11/06/2020, i.e. a shifted by a day earlier.
I tracing a round-trip to the server and back to see if I could identify the source of the problem. The dates were being correctly passed to the server as British Summer Time (+0100) dates, e.g. 11/06/2020 00:00:00 (+0100). The server was correctly converting these into Coordinated Universal Time, e.g. 10/06/2020 23:00:00 and these were being stored in the database. Good practice is to always save dates in UTC as the database server could be located anywhere. It's then the responsibility of the client application to convert the time to a local time (e.g. back to BST).
The problem was when the dates where loaded back from the database. On inspecting the dates, I saw that the DateTime property kind was set to Unspecifed instead of UTC. This had the effect that when the date was returned to the client, it treated it as a local time and did't convert it to a local time. The client application uses a formatting pipe to show just the date part, so that was why the dates were showing as a day early.
I found a solution to this problem which involved registering a ValueConverter that set Kind to UTC. This worked nicely and now my dates are displaying correctly in the application.
The underlying issue here is that the datetime2 SQL Server type (that Entity Framework maps to the .NET DateTime type) simply stores a date and time and has has no additional information about the time-zone. As such, Entity Framework cannot make the assumption that it is a UTC time. However, newer versions of SQL server now have a new type datetimeoffset which includes the storage of the timezone. Entity Framework maps this to the .NET DateTimeOffset type, so this should be used instead to avoid this sort of issue.
Pagination
The final user story for this sprint was to fetch some boat details from the API and then present them as 'cards'. For this I wanted to use pagination so that only a fixed amount of boats were returned and I could fetch pages using a page navigational.
Loading Indicators
One thing I noticed as I was testing the application is that sometimes there is a small delay after clicking a link or a button if the application is making a round-trip to the server. I suspect that this is because I'm using the cheapest app service and database tiers for testing and these use shared resources. So if left for a while, it will need to re-spin up those resources, hence the delay. However, to prevent users from double clicking on buttons, I'll need to add some loading indicators (spinners) while the application is asynchronously waiting for a response. Here are a couple of articles that describe how to implement such a strategy: Loading indication in Angular and How to easily display loading indicators. Also here's a stack overflow with some info on this.
Asset Labels
When designing the database tables for the inventory, I wanted to take what I'd done in 2017 on the boat inventory, but make it a little more generic so it could manage any sort of club equipment, rather than just boats. This was simple enough, however it did get me thinking about how equipment could be identified. Currently a 3 part identifier is used for boats. The first part is always the same and the second part identifies the boat type and the third part is a number. I think it would be a lot simpler to have just a serial number for all pieces of equipment and use asset tags in the same way as companies do when tagging computer equipment. I found this company that sell rolls of 1000 tags for about £40. These are waterproof and have strong glue. They can be printed to include contact details to use if the equipment is lost.
No comments:
Post a Comment