Closed siqbal181 closed 5 months ago
FYI, for anyone looking at this. @siqbal181 and I discussed that @kikilondon was already working on this and had added data to the database. The actual current solution is not too important as long as the two versions are reconciled.
@siqbal181, let me know if you would like to push this through until we have more clarity and make changes as we understand our functional needs or if you want to discuss with @kikilondon first.
@siqbal181, let me know if you would like to push this through until we have more clarity and make changes as we understand our functional needs or if you want to discuss with @kikilondon first.
I've send a message to @kikilondon in the discord about me holding off just not to confuse things. so will keep it here for now unapproved! @pablisch
@pablisch @siqbal181 I already created the database on MongoDB; as discussed during the Tuesday meeting, I was in charge of that. Apologies, I didn't add the ticket; I am still familiarizing myself with the process. I will add it now so I won't create confusion.
About the suggestion Pablo made on Discord, I will update the database about opening and closing times and fix the Tate array.
@pablisch @siqbal181 I already created the database on MongoDB; as discussed during the Tuesday meeting, I was in charge of that. Apologies, I didn't add the ticket; I am still familiarizing myself with the process. I will add it now so I won't create confusion.
About the suggestion Pablo made on Discord, I will update the database about opening and closing times and fix the Tate array.
No worries on the ticket. I tried to add you but did not know your github name at the time. You and Sidra are now on that ticket.
I edited the Tate list on you csv but not in the database. I'm guessing you imported it but have never worked with DBs and csv so wasn't sure.
About the open/close, facilites, overall structure... there are lots of things we may decide we need to change later once we start to use the data so I'm happy for us to make the changes as we go along with a very limited starting data set. So, really happy for you and Sidra to decide on the best working data structure for now and not feel you need to make changes about details we are still not sure about 🙂.
@kikilondon and @siqbal181, things are going so well that I started to think about sprint 2 and realised we will need an image of the cafe. We might well want to display multiple images and although that is not likely MVP, it seems worth planning for it and having an array of image urls of which we will only use index 0 for MVP. Since we might want other details for the image, think about how you want to store that, e.g an array of image objects
[{ url:
@kikilondon and @siqbal181, things are going so well that I started to think about sprint 2 and realised we will need an image of the cafe. We might well want to display multiple images and although that is not likely MVP, it seems worth planning for it and having an array of image urls of which we will only use index 0 for MVP. Since we might want other details for the image, think about how you want to store that, e.g an array of image objects [{ url: , title: , altText: }]
@kikilondon @pablisch Thanks Pablo! just made a few changes before the call at 5 to be up for discussion. Encorporated the image suggestion too and changed the facilities to be just an array of strings vs. encapsulated in an object
I just added an on-hold label to this PR so it is obvious. Just remove the label when it is ready for review.
@pablisch I am researching MongoDB, and having a simple array of "must have" is straightforward and can work well if you only need to store a list of must-have features. However, it may be less flexible if we plan to add more details about each "must-have." But as far as I know, we didn't plan to add any of this info even after the MVP. On the other hand, using an array of objects will only allow us to store additional information if we plan to do so later. React native is not an OOP language, and it may be easier to work with a simple array of strings as these structures are more straightforward to manage and manipulate in a non-OOP environment. I am not working on the MongoDB database; we have not yet revised the user journey, the acceptance criteria and the design, so there is no point in doing so.
We must also consider how we plan to interact with the data in the Aura application (CRUD opeartions) and how we will query and update the data in MongoDB. Some data can be updated, filtered, and sorted through queries in Mongosh. Tbh, I don't know too; when the user selects the facilities he/she wants, those are their "must-have".
I agree that an array of requiredFacilities would be easiest to deal with but you raise a good point about future use. My main concern was data integrity in that facilities and requiredFacilities could hold duplicate data but I don't think this is a huge issue and since we are not clear about any future requirements I think we should go with a requiredFacilities array unless anyone feels strongly otherwise.
NOTE: PR #39 contains all of this PRs branch as we needed the Model so better to branch off that and make any changes there.
@kikilondon I would not let React being functional influence the data type, i.e. array vs object, as JS is still nominally OOP at least and as I understand it, OOP relates to the use of class objects rather than standard data types such as JS objects.
As soon as we do have an agreed Cafe Model, it would be great to have some limited seed data as we are already using the database now and are waiting on that. Happy to do this if you do not have time. I don't think there is anything waiting in the user stories that should affect this.
All the CRUD operations will go through our API via frontend requests. I might be missing the point here so please ask more but maybe better to move that to Discord. Current plan is to have tap to select facility, double-tap or press-and-hold to select as requiredFacility (must have).
This PR has now been superseded
The structure is totally changeable, just a start