feat: Add support for p5.js version check

[dhruvdutt]

This PR is initial WIP to add support p5.js version check as described in #144

Server: ☁️

• Exposes p5.js latest version at new API endpoint: /api/p5version/

Client: 💻

• Check for latest p5.js version during initialization using above API

TODO 👷

• Fix re-rendering issue
• Version checks during "new project" action

Fixes #144 🐛

Thank you!

[dhruvdutt]

@catarak Can you please look into this issue?

After fetching p5 version from api, I'm setting in into files reducer and the state gets updated (check screenshot: redux dev tools section).

The issue is that the html file markup inside editor is not getting updated.
Possibly, this could be the issue

p5.js-web-editor/client/modules/IDE/components/Editor.jsx

Lines 147 to 156 in ea02d76

	componentWillUpdate(nextProps) {
	// check if files have changed
	if (this.props.files[0].id !== nextProps.files[0].id) {
	// then need to make CodeMirror documents
	this.initializeDocuments(nextProps.files);
	}
	if (this.props.files.length !== nextProps.files.length) {
	this.initializeDocuments(nextProps.files);
	}
	}

Also, a note that I'm setting default one to 0.5.0 in the initial state so that we can see the updated one (0.6.0) from the API.

[catarak]

i think the code you've pieced out is probably the issue—it's somewhat hacky code i wrote to figure out if there are any changes the the files, which is obviously not robust. would be awesome to update it!

[catarak]

i also just had an idea—since the p5 version isn't changing that often, maybe it would make sense to store it in mongo or something, and add a script that checks that URL every day or every hour or something? or maybe add a CI task that every time there's a tagged release in the p5 repo the editor gets updated? what do you think? and then i guess the p5 version would get passed to the client when rendered from server/views/index.js, like bootstrapped data?

[dhruvdutt]

i think the code you've pieced out is probably the issue

I think it will take a while to investigate it. We should certainly fix the hack but is this version check a priority? Fixing the hack is a priority for sure.
Did we get stuck in any others issues because of this hack?

store it in mongo or something

Makes complete sense to do it. I also thought to cache it somewhere as this API call takes up at least 200 ms to complete which directly impacts our startup time/new project creation time. We should definitely deploy a cron job at server or setup CI based on tagged release but things will ultimately boil down to where we're stuck in the component lifecycle.

[catarak]

i don't know if there are any other issues, but yeah, it would be great to make the code more robust and clean.

to your second point, one thing i've been thinking about is stuff that can be done server side. it would be cool if certain data could be bootstrapped (something like this: https://medium.com/@baphemot/understanding-reactjs-data-hydration-initialization-bacbb790c7cb)

[catarak]

closeed this PR since it seems to be stale. feel free to reopen if you're still working on it!