Upgrade to ipfs@0.41

[zebateira]

Closes #347

[zebateira]

@terichadbourne so I've created two PRs for us to see the differences between the two options that I see moving forward:

1. ipfs@0.41 update: option 1 #384 Use for await...of loop

• Still working out how to solve the linting warnings on the monaco editor
• Although it looks a bit convoluted, it might be a better choice if we don't want to introduce a module when teaching

2. ipfs@0.41 update: option 2 #385 Use it-all package

• A bit more clean but it might be confusing for users to understand where to use the all function

[zebateira]

IMHO, I prefer the second option since it reduces the complexity of the code a lot. We need to consider that the last lessons of the tutorials would get much more complex with a lot of for loops if we don't use something like it-all.
We just need to explain to the user why we need to use it and include it in the initial code solution as much as possible.

[zebateira]

Update

Regarding all the points mentioned in #385 (comment) I think I've addressed them all except for:

• More detailed explanation about Async Iterables
• Add small observation to users that have completed the tutorial in the past and are now coming back to it: the cached code will not work anymore (@terichadbourne I think we could do this in a separate PR? just so split things up)

[zebateira]

@terichadbourne ready for review, will address the "warning" message in another PR

[terichadbourne]

@alanshaw Thanks for offering to give this one a proof!

Note that we'll also be adding a few callouts that appear only to folks who already visited the previous version of the affected tutorials, so what you're seeing is the text for new visitors.

[alanshaw]

Just a quick drive by comment...I'm hesitant to use it-all in examples or tutorials because of https://tc39.es/proposal-iterator-helpers/#sec-asynciteratorprototype-toarray - which will eventually allow you to await ipfs.add(files).toArray() to do the same thing without the use of an external module (more info here https://github.com/tc39/proposal-iterator-helpers).

Also because, where possible, I'd like to avoid buffering content into memory because:

[...] we should provide APIs that a) encourage developers to do the right thing and not buffer content into memory regardless of the size of the file they’re retrieving and b) reduce time to first byte, giving users visibility over progress and allowing them to differentiate between the file being unavailable or it being very large.

https://blog.ipfs.io/2020-02-01-async-await-refactor/#1-streaming-by-default

[terichadbourne]

Any sense of how long "eventually" will be @alanshaw? I'd argue that if "using a thing that lets you nicely turn stuff into an array" is the preferred/easier method we want to teach, then rather than rip out the it-all and making the lessons harder by requiring all the JavaScript looping it might make more sense to add a note about the hopefully-upcoming-built-in-thing and let people know it will (hopefully) produce the same results as it-all does and we'll come back and update the content when that becomes available.

Probably worth us both working through the content in full to see how it flows before we decide.

[alanshaw]

Any sense of how long "eventually" will be @alanshaw?

Not at all. It is currently at stage 2.

I'd argue that if "using a thing that lets you nicely turn stuff into an array" is the preferred/easier method we want to teach, then rather than rip out the it-all and making the lessons harder by requiring all the JavaScript looping it might make more sense to add a note about the hopefully-upcoming-built-in-thing and let people know it will (hopefully) produce the same results as it-all does and we'll come back and update the content when that becomes available.

That's fair, and I have no desire to make lessons harder, but if we're going to be turning stuff into an array and then looping over it we should consider just using a for loop instead (for example). I'll take a look tomorrow but I expect @zebateira has made sensible choices already.

[alanshaw]

...there's also the small problem of require not being available in the browser and all the explanation you'd need to do around that 😅

[terichadbourne]

Little UI bug: There used to be a white box around the log output, which still exists on the live site but not in this PR (and IIRC not in the Anatomy of a CID PR):
live site:

this branch:

[terichadbourne]

@zebateira You had mentioned something about CID formatting in a chat recently. Just confirming the the format logged below is genuinely what's returned by IPFS, not you making it prettier or wrapping it in CID()?

[zebateira]

@alanshaw

...there's also the small problem of require not being available in the browser and all the explanation you'd need to do around that 😅

Gosh I missed that. I guess we can make it global just like ipfs. @terichadbourne thoughts? Given this I think we should remove the require functionality and add the all to the globals as well.

[zebateira]

You had mentioned something about CID formatting in a chat recently. Just confirming the the format logged below is genuinely what's returned by IPFS, not you making it prettier or wrapping it in CID()?

@terichadbourne What I mentioned is that I am formatting it to show CID() otherwise the output would be:

[zebateira]

@terichadbourne

Little UI bug: There used to be a white box around the log output, which still exists on the live site but not in this PR (and IIRC not in the Anatomy of a CID PR):

Fixed!

[zebateira]

@terichadbourne I think I went over all your suggestions now! Let me know if there's anything else missing.