Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the handling of map options #4145

Merged
merged 2 commits into from
May 23, 2024
Merged

Improve the handling of map options #4145

merged 2 commits into from
May 23, 2024

Conversation

vicb
Copy link
Contributor

@vicb vicb commented May 21, 2024

Content of this PR:

  • Fix comments in type MapOptions
  • Order default values using the type order,
  • Update Map props:
    • use inline init where applicable
    • fix types where applicable
    • fix init to match type where applicable
  • A few other minor updates

I'd like to get some feedback and I'll create an issue and fill out the launch checklist after that.

Thanks!

Launch Checklist

  • Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
  • Briefly describe the changes in this PR.
  • Link to related issues.
  • Include before/after visuals or gifs if this PR includes visual changes.
  • Write tests for all new functionality.
  • Document any changes to public APIs.
  • Post benchmark scores.
  • Add an entry to CHANGELOG.md under the ## main section.

@codecov-commenter
Copy link

codecov-commenter commented May 21, 2024

Codecov Report

Attention: Patch coverage is 88.37209% with 15 lines in your changes are missing coverage. Please review.

Project coverage is 86.87%. Comparing base (d7cd701) to head (df31dcf).
Report is 4 commits behind head on main.

Files Patch % Lines
src/ui/map.ts 84.09% 4 Missing and 10 partials ⚠️
src/util/test/util.ts 0.00% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4145      +/-   ##
==========================================
- Coverage   86.88%   86.87%   -0.01%     
==========================================
  Files         242      242              
  Lines       33044    33075      +31     
  Branches     2011     2017       +6     
==========================================
+ Hits        28709    28734      +25     
- Misses       3374     3383       +9     
+ Partials      961      958       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

src/ui/map.ts Show resolved Hide resolved
src/ui/map.ts Outdated Show resolved Hide resolved
* See https://medium.com/terria/typescript-transforming-optional-properties-to-required-properties-that-may-be-undefined-7482cb4e1585
*/

export type Complete<T> = {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was actually thinking of removing this folder entirely, and move the types to either the utils folder or the files that are using those.
I also don't see this is used in another place, so I'm not sure there's an actual need to move it...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer not to have too much noise in map.ts but no strong opinion, I can do whatever you think is best.

One other unrelated question, do you know why const defaultMinZoom = -2;?
I would love to add a comment there because it doesn't look intuitive

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No clue why it's -2.

If you prefer no to put it in map.ts I would recommend adding it to the utils file.
Also the tilejson and remove this folder completely.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-2 is to render maps < 512px (see mapbox/mapbox-gl-js#9028)

@HarelM
Copy link
Collaborator

HarelM commented May 21, 2024

I don't have any objections to this PR in general.
Can we close the following PR:

@vicb
Copy link
Contributor Author

vicb commented May 21, 2024

I don't have any objections to this PR in general. Can we close the following PR:

For now style is not addressed in this PR but I think it should be.
Let's close the other PR once this has been updated.
The first commit is only about cleaning the existing stuff. I'll add more commits to improve the type after we agree on the first one.

@vicb vicb force-pushed the mapopttype branch 4 times, most recently from 22aed2a to 093c84c Compare May 22, 2024 08:15
@vicb
Copy link
Contributor Author

vicb commented May 22, 2024

It looks like some tests are failing...
I'll try to reproduce locally and fix

@HarelM
Copy link
Collaborator

HarelM commented May 22, 2024

I'm not sure the failing test is your fault. I see it on a PR for a package update.
Wait a bit with the investigation...

src/ui/map.ts Outdated
if (this.style) {
this.style.setEventedParent(null);
// transformStyle relies on having previous style serialized.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a bug fix? If so, I think it will be better to have this in a different PR...?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only code factorization:

  • this.style is tested on l 1732, 1737, and 1738 on the left
  • options.transformStyle is tested l 1732 and 1737 on the left

src/ui/map.ts Outdated
getImage(id: string): StyleImage {
return this.style.getImage(id);
getImage(id: string): StyleImage | undefined {
return this.style?.getImage(id);
Copy link
Collaborator

@HarelM HarelM May 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this a behavior change? As far as I understand, before this change if style was not defined, this method would have thrown an exception, wouldn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed offline with @HarelM

Summary of the discussion: What is the expected behavior of this function:

  • throw is not documented
  • the type of this.style: Style does not let users think it might throw
  • is it valuable to throw here?

I think the behavior should be consistent across methods.

Some might throw:

    getImage(id: string): StyleImage {
        return this.style.getImage(id);
    }

Some are noops when style is undefined

    redraw(): this {
        if (this.style) {
            // cancel the scheduled update
            if (this._frameRequest) {
                this._frameRequest.abort();
                this._frameRequest = null;
            }
            this._render(0);
        }
        return this;
    }

Some warn when style is undefined

   _updateDiff(style: StyleSpecification, options?: StyleSwapOptions & StyleOptions) {
        try {
            if (this.style.setState(style, options)) {
                this._update(true);
            }
        } catch (e) {
            warnOnce(
                `Unable to perform style diff: ${e.message || e.error || e}.  Rebuilding the style from scratch.`
            );
            this._updateStyle(style, options);
        }
    }

@HarelM
Copy link
Collaborator

HarelM commented May 22, 2024

I believe this PR got too big... :-(
Let's try and keep the PRs small, with small increments so these increments can be merged.
From previous commit to latest commit there are a lot of changes which I think should be discussed before merging.
The previous commit was great in terms of adding correctness to types without changing any implementation (maybe besides moving the initialization out of the constructor).
Let's start with that and then move on to fixing things/changing logic.

src/ui/map.ts Outdated
@@ -298,14 +301,15 @@ export type MapOptions = {
* the schema described in the [MapLibre Style Specification](https://maplibre.org/maplibre-style-spec/),
* or a URL to such JSON.
*/
style: StyleSpecification | string;
style?: StyleSpecification | string;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that other improvements are great, I would avoid changing this as part of this PR, keep it as is for now and open a different PR just for this change (with its impact obviously).

Copy link
Contributor Author

@vicb vicb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HarelM

Maybe the best way to move forward is to remove the last commit from this PR.

I can then submit another PR making MapOptions.style optional and dropping all the other changes in that last commit as I don't think you find them useful?

src/ui/map.ts Outdated
if (this.style) {
this.style.setEventedParent(null);
// transformStyle relies on having previous style serialized.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only code factorization:

  • this.style is tested on l 1732, 1737, and 1738 on the left
  • options.transformStyle is tested l 1732 and 1737 on the left

src/ui/map.ts Outdated
getImage(id: string): StyleImage {
return this.style.getImage(id);
getImage(id: string): StyleImage | undefined {
return this.style?.getImage(id);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed offline with @HarelM

Summary of the discussion: What is the expected behavior of this function:

  • throw is not documented
  • the type of this.style: Style does not let users think it might throw
  • is it valuable to throw here?

I think the behavior should be consistent across methods.

Some might throw:

    getImage(id: string): StyleImage {
        return this.style.getImage(id);
    }

Some are noops when style is undefined

    redraw(): this {
        if (this.style) {
            // cancel the scheduled update
            if (this._frameRequest) {
                this._frameRequest.abort();
                this._frameRequest = null;
            }
            this._render(0);
        }
        return this;
    }

Some warn when style is undefined

   _updateDiff(style: StyleSpecification, options?: StyleSwapOptions & StyleOptions) {
        try {
            if (this.style.setState(style, options)) {
                this._update(true);
            }
        } catch (e) {
            warnOnce(
                `Unable to perform style diff: ${e.message || e.error || e}.  Rebuilding the style from scratch.`
            );
            this._updateStyle(style, options);
        }
    }

@HarelM
Copy link
Collaborator

HarelM commented May 23, 2024

Yes, let's drop the last commit and open an issue about the inconsistency of the methods.
Once we agree on the way forward in the issue we can continue to open a PR with the agreed upon changes.
It's not that I don't think they are valuable, it's just that they need a bit more discussion as some of them are breaking changes to public API methods in terms of behavior and I would like to make sure we discuss them properly.
Generally speaking, I agree that the current API is not consistent, and we should dive into it and see what improvements are considered low hanging fruits and what will need a breaking change as part of a breaking change version (see #3834) , but I believe it is out of scope for this PR.
In general, I would prefer to better document the current behavior in types and method docs as an initial non-breaking-change manner, and then later on, if needed, change the behavior as part of a breaking change version.

Copy link
Collaborator

@HarelM HarelM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

THANKS!

@HarelM HarelM merged commit 6d49f57 into maplibre:main May 23, 2024
15 checks passed
@vicb
Copy link
Contributor Author

vicb commented May 23, 2024

Thanks for your help Harel!

@vicb vicb deleted the mapopttype branch May 23, 2024 07:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants