-
Notifications
You must be signed in to change notification settings - Fork 7
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
[Unité] Ajout des bases sur la carte #2726
Conversation
9cf76c8
to
131279a
Compare
const id = `${code}:${entityId}` | ||
|
||
this.code = code | ||
this.entityId = entityId |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pourquoi ne pas rajouter ces deux propriétés dans les properties
de la Feature
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oui en interne dans la classe pour respecter le pattern des Features OL mais si on passe par des getters pour les récupérer, sinon on en perd tout l'intérêt (garantie d'existence).
@@ -0,0 +1,9 @@ | |||
import type { Coordinates } from '@mtes-mct/monitor-ui' | |||
|
|||
export function ensureCoordinates(value: any): Coordinates { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dans quel cas on n'a aucune idée du type de l'input ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
C'est simplement pour TS qui considère que c'est peut-être undefined
à chaque fois qu'on utilise une méthode OL renvoyant des coordonnées, ce qui alourdit vachement le type-checking sans ce petit helper.
C'est aussi plus safe qu'un as
qui ne génère pas de vrai check JS. J'hésite à faire pareil avec un ensureExtent()
.
@@ -62,6 +66,19 @@ export const clickOnMapFeature = (mapClick: MapClick) => (dispatch, getState) => | |||
return | |||
} | |||
|
|||
if (mapClick.feature instanceof FeatureWithCodeAndEntityId && mapClick.feature.code === MonitorFishLayer.STATION) { | |||
const overlayPosition = getDialogOverlayPositionFromFeature(mapClick.feature, 334, 320, FEATURE_MARGINS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ici, je préfère qu'on utilise le standard getId()
comme sur les autres features
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pas de soucis mais alors je propose que l'on override la méthode getId()
. L'idée et d'éviter ce genre de code à rallonge qui ne fait finalement que getter une simple propriété dont on sait pertinemment qu'elle existe.
OL a l'avatange d'être hautement extensible, je pense qu'il ne faut pas s'en priver.
Même si je pense aussi que les getter et setter en JS existent depuis un bail maintenant et getId(
) n'est que le prédécesseur d'ECMAScript 6 (2015) class{ get id() {} }
. Mais ça c'est seulement du taste donc aucun soucis si ce n'est pas partagé.
J'ai écrit tout ce code comme une proposition généralisable.
function UnmemoizedStationLayer({ hoveredFeatureId }: StationLayerProps) { | ||
const vectorSourceRef = useRef(new VectorSource() as VectorSourceForFeatureWithCodeAndEntityId) | ||
const vectorLayerRef = useRef( | ||
new VectorLayerWithCode({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ici aussi on pourrait utiliser le VectorLayerWithName
existant ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
VectorWithName
est juste un type non ? Il ne garantit pas l'existence des props.
|
||
useEffect(() => { | ||
vectorSourceRef.current.forEachFeature(feature => { | ||
feature.setState({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setState
n'existe pas à mon sens, enfin pas pour set les propriétés d'une feature
https://openlayers.org/en/latest/apidoc/module-ol_VectorTile-VectorTile.html#setState
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oui je l'ai nommé comme ça sans grande inspiration. Mon idée est de nommer cette méthode de manière à symboliser quelque chose qui va être muté selon les besoin une fois la feature instancié, contrairement aux props. Et que ce soit sur Env ou Fish on a un commun assez important sur le isHighlighted
et le isSelected
entre les layers. Je suis preneur de meilleures idées :).
return () => { | ||
monitorfishMap.removeLayer(vectorLayerRef.current) | ||
// eslint-disable-next-line react-hooks/exhaustive-deps | ||
vectorLayerRef.current.dispose() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dispose
n'est requis que pour les layers en webgl ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Là j'avoue que je colle, je te fais confiance du coup. Je veux bien une petite explication quand je reviendrai sur la logique de cleanup dans OL.
import type VectorSource from 'ol/source/Vector' | ||
|
||
export interface VectorSourceForFeatureWithCodeAndEntityId<G extends Geometry = Geometry> extends VectorSource<G> { | ||
addFeatures(features: Array<FeatureWithCodeAndEntityId<G>>): void |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je ne suis pas super fan de ces re-typages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Je suis d'accord et propose qu'on crée une classe étendue VectorSourceForFeatureWithCodeAndEntityId
(ou un autre nom) étendue alors. FeatureLike
garantit seulement le minimum requis pour une Feature
, l'idéal serait de garantir que l'on ne manipulera que des FeatureWithCodeAndEntityId
.
131279a
to
b92d88f
Compare
@louptheron Il reste :
J'ai rebase la branche sur #2722 qui lui-même a été rebase sur master aujourd'hui. Je te conseille de merger cette PR-là en prio puis de rebase celle-là sur master pour simplifier le process. |
4dfc2a6
to
85adf92
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Linked issues