Skip to content
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

separate legacyShareStyle from isLegacyShare #22615

Merged
merged 1 commit into from May 25, 2018

Conversation

cpirich
Copy link
Contributor

@cpirich cpirich commented May 23, 2018

  • We had two concepts related to legacy share in our code base:
    1. We wanted the share to appear in a "legacy style" - this impacted who was responsible for drawing the footer and a few other things. Only applab shares were not "legacy style"
    2. The share was from our legacy method of sharing, a /c URL share, meaning that it referenced a level source id and not a project id
  • Unfortunately, some code was conflating the two into the same thing. This caused "send to phone" to stop working for the gamelab share page, and may have caused some other issues.
  • Separated the two, by creating legacy_share_style (aka legacyShareStyle) for the former and sending the existing is_legacy_share (aka isLegacyShare) for the latter. As we currently stand, isLegacyShare and legacyShareStyle can both be set at the same time, or legacyShareStyle can be true by itself.
  • Modified the places where we used isLegacyShare in the apps code to choose the appropriate variable to key off of.

@@ -523,7 +523,7 @@ var projects = module.exports = {
this.sourceHandler.setInitialLevelSource(currentSources.source);
this.showMinimalProjectHeader();
}
} else if (appOptions.isLegacyShare && this.getStandaloneApp()) {
} else if (appOptions.legacyShareStyle && this.getStandaloneApp()) {
Copy link
Contributor Author

@cpirich cpirich May 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only one I'm not certain on. Are we trying to determine if we're a /c share URL here? We're outside of the this.isProjectLevel() check. One reason to choose legacyShareStyle is that it is true in all of the places where we previously had set isLegacyShare to true - so I'm not changing any behavior.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment on showMinimalProjectHeader() reads

// Minimal project header for viewing channel shares and legacy /c/ share pages.

which I think means you've got it right - we want the minimal header in both cases.

// and playlab). So instead, we check the first letter (after the /) in the path name of the
// url, as legacy shares all start with /c
// var isLegacyShare = this.props.isLegacyShare;
var isLegacyShare = window.location.pathname[1] === 'c';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code had noticed that something was wrong (the comment says isLegacyShare currently has the wrong value) - but the fix was hacky and narrow in scope.

view_options(no_header: true, no_footer: true, code_studio_logo: true)
@is_legacy_share = true
view_options(no_header: true, no_footer: true, code_studio_logo: true, is_legacy_share: true)
@legacy_share_style = true
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this controller, we set both is_legacy_share and legacy_share_style

@@ -300,7 +300,7 @@ def show
# for sharing pages, the app will display the footer inside the playspace instead
no_footer = sharing
# if the game doesn't own the sharing footer, treat it as a legacy share
@is_legacy_share = sharing && !@game.owns_footer_for_share?
@legacy_share_style = sharing && !@game.owns_footer_for_share?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the projects controller, we only ever set legacy_share_style (in some cases)

@islemaster
Copy link
Contributor

Quick inventory of things now determined by legacyShareStyle:

  • Add classes legacy-share-view and legacy-share-view-mobile to body
    Show addToHome on iOS
    (StudioApp.js:263)
  • Call setupLegacyShareView, which causes studioApp to create/own the phone frame.
    (StudioApp.js:471)
  • Factors into Chromeless share decision
    (StudioApp.js:1921,1931)
  • setName('Untitled Project') and show minimal project header
    (project.js:526)
  • Light or dark icons in turtle
    (artist.js:330)

I wonder if we don't want to use the "legacy share" description for this at all, to avoid confusing this with /c/ routes. Maybe even renaming it to nonStandardShareStyle or something? It's a little weird that we call it legacy but use it for all AppLab and WebLab shares (I think?)

@cpirich
Copy link
Contributor Author

cpirich commented May 25, 2018

Correct, I believe it is everything except AppLab/WebLab, though WebLab now bypasses this share mechanism completely and shares via codeprojects.org. My sense is that we thought we might migrate more apps over to the newer "applab" style, but never got around to it.

I thought about choosing a different name, but since we have classes like legacy-share-view and functions like setupLegacyShareView(), I didn't want to confuse things further by introducing a different name which triggers those things. (Using legacy share view in response to seeing something called legacy share style sort of makes sense to me). Of course, I could keep going and rename those classes and functions.

@cpirich cpirich merged commit a7eeb54 into staging May 25, 2018
@cpirich cpirich deleted the fix_legacy_share_confusion_and_send_to_phone branch May 25, 2018 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants