-
Notifications
You must be signed in to change notification settings - Fork 250
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
Export public API via index.js #157
Conversation
Resolves #153 |
writeBinaryGltf : require('./lib/writeBinaryGltf'), | ||
writeGltf : require('./lib/writeGltf') | ||
}; | ||
AccessorReader : require('./lib/AccessorReader.js'), |
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.
Are you sure you want to expose all of this? That is a lot of API surface area. We learned a very hard lesson in Cesium to only expose what is needed to keep the maintain cost way down.
Please only expose what is currently needed and make sure the public API has full reference doc that can be generated like we do for Cesium. Don't worry about the generated doc's styling or hosting right now.
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.
There's still way too much API surface area here. @lilleyse and @lasalvavida can you please take a pass over this?
I can help if needed, but I would rather you guys get the experience working with APIs. At this point, I would only expose top-level stages and helpers that @likangning93 needs. Anything else is a high-cost loan for money we don't need.
I've gone through and trimmed down what we are putting into the public API. Everything exposed now has documentation. It probably isn't perfect, but it is a good starting point. Things that are exposed: "stages", and helper functions that are fairly glTF specific i.e. |
I also moved |
@likangning93 I have exposed everything listed in #153, let me know if there's anything else you want exposed that I missed. |
Also making a note here that combinePrimitives is not currently exposed. It should be exposed once #108 is resolved. |
writeBinaryGltf : require('./lib/writeBinaryGltf.js'), | ||
writeBufferComponentType : require('./lib/writeBufferComponentType.js'), | ||
writeGltf : require('./lib/writeGltf.js') | ||
}; |
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.
The main problem with exposing a lot of these functions is that they may rely on previous steps, like addPipelineExtras
. Either we need to handle that in the functions themselves, or expect users to call things like addPipelineExtras
, loadGltfUris
, etc on their own.
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.
Would it be enough to just put the dependencies in the doc until we work out custom pipelines?
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.
Yeah I think that's ok for now.
I just made minor edits. Thanks for adding all this documentation and fixing a bunch of problems you noticed. I organized some of the requires to follow the node guide, where Cesium functions are set after all the requires:
|
* Add pipeline extras and load uris, then process the gltf. | ||
* | ||
* @param {Object} gltf A javascript object holding a glTF hierarchy. | ||
* @param {Object} options Options to apply to stages during optimization. |
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.
In some areas like this the options aren't documented.
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.
We pass options to stages and they should be documented for all of those. I think it would be a bit verbose to document all of the different stage options here.
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.
Well it may be redundant in some cases. Maybe just make a note to refer to the processJSONWithExtras
doc.
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.
Ah you beat me to it.
@lilleyse updated |
The new changes look good. @pjcozzi feel free to do a final check. |
getUniqueId : require('./lib/getUniqueId.js'), | ||
gltfPipeline : require('./lib/gltfPipeline.js'), | ||
loadGltfUris : require('./lib/loadGltfUris.js'), | ||
mergeBuffers : require('./lib/mergeBuffers.js'), |
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.
I just noticed that there isn't doc for this one.
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.
Never mind...
Add instructions for building doc to the README.md. |
Throughout, the doc needs a lot of work. I am fine with merging this to get the mechanics and then writing more solid doc for a code sprint or something like that, see #163. @lasalvavida before we merge this, can you please take a pass through our Documentation Guide to see if there are other things we should get into this PR? |
* @param {Number} componentType WebGLConstants value for component type. | ||
* @param {Number} value The value to write. | ||
* @param {Number} byteOffset The offset into the buffer to be written. | ||
*/ | ||
function writeBufferComponentType(buffer, componentType, value, byteOffset) { |
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.
Why does this function need Component
in it? Why not just writeBufferComponent
? This writes one component to a buffer, right? The "type" doesn't need to be explicit in the name.
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.
Same comment for readBufferComponentType
.
@lilleyse can you please scrub this public API to make sure the naming and general patterns follow Cesium's best practices? I could a few things with a quick look, but I suspect there are more from old code...not necessarily changes in this PR...but I want to get the initial public API as close to right as possible even if it won't be widely used for a while. |
@lasalvavida this is a huge step in the right direction, thanks for starting to kick this into shape! |
Updated, @lilleyse, this is ready for a look. |
Updated |
I did some general cleanup which someone else should look over before I merge. The recent changes to index.js seem good to me. |
@@ -28,16 +26,18 @@ module.exports = { | |||
optimizeCache : require('./lib/optimizeCache'), | |||
packArray : require('./lib/packArray'), | |||
parseBinaryGltf : require('./lib/parseBinaryGltf'), | |||
Pipeline : require('./lib/Pipeline'), |
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.
Is this correct? Shouldn't the capitalization put this first?
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.
Oh, I didn't know that was a common thing to do. If so I'll correct it.
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.
@mramato, I can't find a point of reference for this. Which way should this go?
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.
It doesn't really matter in this case. Since this won't be auto-sorted, whatever you guys want to do is fine.
Updated. |
@lilleyse Is there anything else we need to do here or is this good to merge? |
I think this is good to go. Once we publish to npm we will have to remember to update several projects because of the |
All lib/*/.js functions are exposed via index.js. Also adds a gulp task for regenerating this file.A collection of functions are exposed as the public API. They are all documented.