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

[Feat] Support for Polygon and Polyline #435

Open
BoveFabio opened this issue Jun 27, 2024 · 3 comments
Open

[Feat] Support for Polygon and Polyline #435

BoveFabio opened this issue Jun 27, 2024 · 3 comments

Comments

@BoveFabio
Copy link

Target Use Case

While I can already easily use many components like (advanced) markers, there is currently no polygon or polyline support. Obviously, it is possibly to write some code myself or even take the code from your geometry example in this repo. But it would be nice if polygon and polyline became officially supported.

Proposal

The basis is already there in the geometry example in this repo. It would probably only take a bit of refinement and could then be offered as a component the same way as markers, for example.

@usefulthink
Copy link
Collaborator

I would argue that we do provide support for the geometry primitives, via the examples.
The key Idea is that we want to use the examples to provide "ready-to-use" components for a wide range of use-cases.
We invested a lot of time into making the examples as good as easy to use as possible and we'll continue adding more examples and improving on the existing ones as time allows.

All the components you find in the examples are intended to be copied into your project.
In a lot of cases you won't even need to change anything. In that ideal case, it won't make much of a difference for you if the component is imported from node_modules or from your own components directory. However, if it doesn't do what you need it to do, it is much better if the file is yours and you can quickly change whatever needs to be changed.

I think this approach allows us to provide a far greater coverage of use-cases with the amount of time we have available to work on this library. The more components we have in the core library, the more time it will take to maintain it, so growing the library itself can only happen if the community maintaining it grows along with it.

If I may ask, which benefits do you see bundling the components with the library instead of having them available to copy and adjust in the examples?

@BoveFabio
Copy link
Author

Hey @usefulthink,
thanks for your thoughts.

I do agree that copying the files definitely is a valid approach, especially because, in this case, they are not very complex. I also understand that you want to use your limited capacity as efficiently as possible and find that very reasonable.

In general, I think providing common use cases on a maintained basis (rather than providing a file to copy) is useful because I can benefit from updates you make to such examples. If, for example, you found a memory leak in your example and fixed it, I would not immediately benefit from that fix. I would need to keep an eye on the example and check for changes on a regular basis (and think about how to apply your fix to my own code and hope that the changes you made don't conflict with adaptations that I made to the file). In short: only one party would need to spend maintenance effort rather than everyone who uses the feature.

Just to be clear: the above is my general opinion about providing common functionalities. Because of the low complexity of the specific examples of polygon and polyline, it's quite trivial to copy the code and adjust it (and maintain it on my own). This is currently no blocker for us, I just think it might be nice to have that feature out of the box in the future.

@sosukofa
Copy link

I do agree with @BoveFabio please make this available so we can use it like how AdvancedMarker components can easily be imported and used.

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

No branches or pull requests

3 participants