join us on Discord for support, updates, and all things Snap AR! See you there!
Why is there so much difference between the documentation for Web SDK development?
I post this as a question and not as a request because I am not a web dev so maybe this is standard, but trying to deploy the WebSDK I've noticed that the three different sources of documentation I've used follow very different approaches.
Currently the one that has given me better results was the one in here.
Yet this is the one that one encounters first. Starting by the bootstrap of the CameraKit there's differences.
Even using this example I kept running into issues in which everything would work until a line was considered TypeScript instead of Javascript.
Are different documentations for different approaches? If so would it be possible to indicate at the top something about it? or is this just growing pains, in which case, which documentation would you recommend as the latest? I am currently using Parcel by Michael's recommendation and it has been way easier than Heroku. I feel I am close to see a lens (I even get the pop up to accept Snapchat terms and services) but is hard to know what I am missing because each approach is so different in the way they call stuff.
Best Answer
-
Hi @aestarita. Thanks for your feedback. Totally valid and apologies for the inconsistencies here while we work through streamlining our documentation. Feel free to share what you have done so far and I can take a look to see what pieces may be missing. We appreciate your patience with us!
0
Answers
-
Hi Michael! Thank you for your answer. I totally understand. Is a product that is moving super fast and it makes sense the documentation is a moving target. I was just curious if there was a more "current" I should be following over the others.
I was able to get it working this weekend though. I think I am going to post later on the board my step-by-step process in case it helps someone else. I feel that one of the things that was the hardest for me was, because I am not a web developer, I wasn't sure once I called things in my main.js script, where I was supposed to reference them afterwards. I also understand that one of the challenges of the documentation is the need of making it both straightforward and thorough to include all possible cases at the same time, and I think that was a bit confusing as well. That's why I felt this one worked the best for me. At the end there's a "and this is how the script should look" section that made it easier to know where I was missing something or where I could add something.
1