-
Notifications
You must be signed in to change notification settings - Fork 163
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
Create version flags #438
Create version flags #438
Conversation
@jywarren
This is great! Thank you for doing this. Question/thought:
@Forchapeatl, what do you think? Do you see any issues with merging this and including the flags into our code moving forward? |
Yes, that should be right!
You can, but we don't have to do it all in one pass. We can migrate anything in
Which files did you think it should be in? Maybe I missed something!
Agreed, let's merge this as soon as i see what you mean in "For clarity, I see that you did not add the version flag code...", and then other work can be rebased on top. Thanks! |
Ok, this sounds good - I also think its best to do this in smaller chunks. For now, index2.html (version 2) in connected to infragram2.js. I will leave this as is until we move everything over and simply add any new functions to both the infragram.js and the infragram2.js files Can you please clarify; would you like us to utilize the version 2 flag on all functions that relate to version 2 or simply those that would break version 1? For example, #436 does not break version 1, (but also does not include the flag).
You added the flag to the src/Infragram.js file. I was just wondering if we needed to add it to the src/ui/interface.js file (and other src files that we are adding-to/changing). Infragram.js requires those modules, I just wasn't clear on whether that is sufficient. I actually think we're covered and can change anything later if need be 👍 |
Oops, my apologies for missing this --
I think only when necessary - that is, when not using the flag would break v1. Many additions simply address HTML bits that don't exist in v1, so they won't break anything if included. However, I think that it's good to mark such additions with a comment noting that they are for v2, so that we know what we can clean up later when we remove v1 code! |
Well, once we include that flag in the main options parameter, it's accessible from most of the sub-files. See how we pass in the options object here: Line 5 in 86b2ddb
Then it's accessed within the file here: Line 3 in 86b2ddb
And you can see us using it here: Line 111 in 86b2ddb
Any subfile in /src/ which you see with the same options object passed through works in the same way, so that all options are consolidated. Does that make sense? |
Hi @Forchapeatl @stephaniequintana I just merged this - so you can now access it like: |
It does make sense. Thanks for clarifying 👍 |
We haven’t discussed this specifically yet. With this merge, if we can include the flag on any outstanding and new PRs (where necessary), there should only be a few instances that we’ll need to address. To help keep things organized, I propose that we do this after we merge @Forchapeatl’s latest work into version 2. I’ll touch base with @Forchapeatl and add this to our running thread. |
Great!
Sounds excellent. |
Fixes #0000
Make sure these boxes are checked before your pull request (PR) is ready to be reviewed and merged. Thanks!
@publiclab/reviewers
for help, in a comment below