Digital Guide structure tab

[24bartixx]

What's been done

• level page
• region page
• region data models initialized (lifts, ramps, lodges, stairs....)
• region data repository for all of the following pages (lifts, ramps, lodges, stairs....)

Screens

Implemented pages

• level page
• region data page
• corridor page

level_view -> region_view -> corridor_view

Pages to be implemented (probably new tasks)

• dressing room page (szatnia)
• information point page (punkt informacyjny)
• lift page (winda)
• lodge page (portiernia - already in tasks)
• parking page (different than in-app parking functionality)
• ramp page (pochylnia)
• stair page (schody)
• stairway page (klatka schodowa)
• toilet page (toaleta)
• door page (drzewi - already in tasks - I assigned myself)

Android Emulator / IOS Simulator vs physical device

• Comparison 1

• Comparison 2

Do you happen to know why in IOS Simulator and Android Emulator the spacing in some places is so extended? On physical device it works properly.

[tomasz-trela]

Looks good to me !! A lot of work with defining models here. There are a few suggestion from me. Comments refer to every place in code where you can apply it (not only marked places) .

[mikolaj-jalocha]

Huge part of code here, but mostly coded well. I like the job you've done with creating models for everything that was needed. It will reduce scope and complexity for other tasks. Everything in terms of them looks good to me.

I left my suggestions, questions and opinions in the comments, let me know wdyt. (domain layer, typedef )
No.1 priority here is to divide large files/widgets into smaller parts in a way that they can be reused, 318 lines of code don't look nice xd

[simon-the-shark]

yeah, so I'm not making a full review at the moment, but what Tomek and Mikołaj noted is very valid.

definietetly this region data should be in some domain/business layer. Would consider using typedef and record instead of freezed. Those repositories need to go to proper files in the tabs folder, where they will be reused. And some other repetition as Tomek noted needs a refactor.

my only note here from me is a thing to test/consider if loading everything together will be acceptable in terms of loading time, cause it needs to hit 20 endpoints or so

For you to know in the future, if a PR is that big, it means the scope is bloated. PR is considered HEAVY when it has 600 diff lines, so when you get close to such sizes, it means the task should have been divided.

But good job :) It's nice to see you doing hard and nice work

[simon-the-shark]

don't we have stringToBool somewhere else already?

[24bartixx]

We do in some other models I guess but where should we define it then? It cannot be an extension.

[simon-the-shark]

so this is a question whether we want to load everything at once. If yes then this is cool, but defienietly as Mikołaj noted, this should be some type of domain/business layer, not data layer. And would consider using typedefed Records instead of full freezed model.

but loading everything at once can be heavy to do, cause we have to wait for like 20 endpoints or so. So we gotta test if this is acceptable loading time