Comments (7)
Just documenting the reasoning I followed in #8573:
The peer dependencies used in v9.0:
- Packages that will break if multiple copies are installed
@deck.gl/core
: single-version enforcement; use ofinstanceof
Effect, Viewport in the code base@luma.gl/core
: single-version enforcement; use ofinstanceof
Buffer, Texture, Device in the code base; global device registry@luma.gl/engine
: I was under the impression thatShaderFactory
,PipelineFactory
create global singletons but it doesn't appear to be the case?@loaders.gl/core
: I was under the impression that it used a global registry but it doesn't appear to be the case?
- Packages that are reused to minimize bundle size (other
@deck.gl/*
). Our dev-tools setup lists allpeerDependencies
as externals when building the dist bundle. So that when multiple bundles are used together, they do not include the same dependency twice. The result is that script tag usage mirrors npm usage. Doing so will minimize the combined bundle sizes, should the user choose to selectively include sub-modules with script tags. - Frameworks that the user will want to manage themselves ("true peer dependency"):
react
,react-dom
,@arcgis/core
Reflecting on the above:
- I agree that the number of peer dependencies should be minimized. Although
@deck.gl/core
lists some of these as dependencies, you still get warning/error if you don't list them explicitly. The main module currently triggers a wave of warnings because of this. - I think single-version enforcement is for a good reason. Requiring a single instance, on the other hand, may be excessive, and even troublesome, for example see #8726
- We should get rid of the global singletons in general. They don't port well across the various distribution formats and cause hard-to-debug issues when things go wrong.
- It's possible to remove the various
instanceof
usages but hard to prevent them from creeping back.
from deck.gl.
- luma.gl/core - the device registration could be stored on globalThis. Have also been working on adding a
devices: Device[]
parameter toluma.createDevice
so that global registration is optional. - luma/engine singletons are per device
- luma.gl/shadertools - the ShaderAssembler singleton is still global. We did however discuss moving away from global registration of shader hooks etc.
- loaders does use
globalThis
. so sharing works between multiple versions of the same module - the downside is that this could potentially lead to insanely hard to debug issues if two slightly incompatible versions modified the same global.
from deck.gl.
-
Requiring a single instance, on the other hand, may be excessive, and even troublesome, for example see #8726
- Yes... I am not sure what aspect of single instance that issue refers to.
-
We should get rid of the global singletons in general. They don't port well across the various distribution formats and cause hard-to-debug issues when things go wrong.
- Agreed.
-
It's possible to remove the various instanceof usages but hard to prevent them from creeping back.
- We do need to check runtime types in various functions. If we can't use the built-in functionality we need to add our own type field or some sniffing mechanism. My hesitation is that the solutions I can imagine are ugly enough that we should make sure it is worth it, that it really makes a difference in usage.
from deck.gl.
I am not sure what aspect of single instance that issue refers to
#8726 highlights the fragile setup surrounding @luma.gl/core
.
@deck.gl/core
bundle exposes its copy of@luma.gl/core
via theglobalThis.luma
. The other@deck.gl/*
imports luma core classes from this copy instead of bundling their own, to work around the single-instance requirement.- If the user wants some luma core exports that are not bundled by deck core, or simply by mistake, they include the
@luma.gl/core
dist bundle via a script tag. This will practically introduce a second copy of luma core. The classes inglobalThis.luma
may come from either copy depending on which one is executed first. Now any subsequent@deck.gl/*
and@luma.gl/*
code may break when they referenceinstanceof <core_class>
or a global singleton. - To avoid this, we receive requests to export more luma classes from deck core, raising concerns of bloated bundle size.
from deck.gl.
Well, we could always take another look at the state in luma.gl master (targeting v9.1), which removed the non-essential exports (often by moving them into internal functions in non-core modules).
from deck.gl.
We do need to check runtime types in various functions. If we can't use the built-in functionality we need to add our own type field or some sniffing mechanism
The majority of the usages are in the following pattern:
getAttachment(attachment: string | Texture | TextureView): TextureView {
if (typeof attachment === 'string') {
return createTexture(attachment).view;
} else if (attachment instanceof Texture) {
return attachment.view;
} else {
return attachment;
}
}
Which can be converted to:
getAttachment(attachment: string | Texture | TextureView): TextureView {
if (typeof attachment === 'string') {
return createTexture(attachment).view;
} else if ('view' in attachment) {
return attachment.view;
} else {
return attachment;
}
}
TypeScript won't have a problem with this during type check. If in runtime the user passes in some JavaScript object that is neither Texture or TextureView - the current implementation wouldn't work either.
With that said, we don't have an easy way to prevent these from being added back.
from deck.gl.
TypeScript won't have a problem with this during type check
That would be nice. I have never been able to get the in
operator to do type narrowing, so I would expect that a cast would needed in both that branch and the last one. But typescript evolves, perhaps I should try again.
Even so this will need custom approach in every place.
from deck.gl.
Related Issues (20)
- [Bug] Layer is not cleared when data is empty with version 9 HOT 2
- Add MapTiler in Supported Base Maps [Doc] HOT 10
- [Bug] ScreenGridLayer docs point at incorrect library
- [Bug] autoHighlight on a TileLayer with multiple sub layers HOT 1
- [Bug] Error: Tile3DLayer: Failed to render layer of type cmpt HOT 3
- [Doc] @deck.gl/mapbox description needs to be fixed?
- [Feat] Add a viewport buffer around TileLayer
- [Bug] getPickingInfo doesn't work with Map/Set data HOT 4
- [Bug]Using @deck.gl/[email protected]: deck.getTooltip({object}) the parameter object is undefined. HOT 4
- Warning message from @luma.gl HOT 1
- [Doc] OpenLayers example HOT 1
- [Feat] Specify clearColor per view HOT 4
- [Bug] HeatmapLayer breaks when used with DataFilterExtension and other extensions
- [Bug] cannot reference the same b3dm HOT 1
- [Bug] Tile3DLayer interleaved with Mapbox causes mapbox tiles to flicker HOT 2
- [Doc] AttributeManager.addInstanced behaviour change on upgrade to deck.gl 9.x HOT 2
- [Bug] Widget stylesheet not exported properly HOT 1
- [Doc] Fix code example mistake (using-with-maplibre section)
- MVTLayer zooming artifacts on Deck.GL own documentation website
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from deck.gl.