Skip to content

experiment: Frontend - Share v1 UI via coder/m submodule (Approach 1)#4

Closed
bryphe-coder wants to merge 2 commits into
mainfrom
bryphe/experiment/share-ui-1
Closed

experiment: Frontend - Share v1 UI via coder/m submodule (Approach 1)#4
bryphe-coder wants to merge 2 commits into
mainfrom
bryphe/experiment/share-ui-1

Conversation

@bryphe-coder

@bryphe-coder bryphe-coder commented Jan 5, 2022

Copy link
Copy Markdown
Contributor

This is one possible approach to sharing 'V1' components and styling in the context of an independent 'V2' front-end codebase:

This approach entails:

  • Bringing in coder/m as a submodule
  • Use a special webpack.config.js and tsconfig.json that aliases coder/m references

With this, we can build a stand-alone front-end app that can still pull from the 'v1' codebase to reference components:

/ Code imported from 'Coder v1'
// Legacy components that we can re-use
import { CoderThemeProvider } from "@v1/product/coder/site/src/contexts/CoderThemeProvider"
import { UserContext, defaultAppState } from "@v1/product/coder/site/src/contexts/User"
import { SetupModeProvider } from "@v1/product/coder/site/src/contexts/SetupMode"

// A fun component to bring in as an example of re-using UI from 'v1':
import { ConfettiTransition } from "@v1/product/coder/site/src/pages/Onboarding/Activation/ConfettiTransition"

The components still need scaffolding to be instantiated - for example, the Confetti Transition requires a 'setup mode' context and a 'user context', so we have to provide those (just stubbed out):

const renderLegacyComponent = (component: JSX.Element) => {
  const fetchSetupMode = async () => {
    // Return an empty response for 'setup mode'
    return {
      body: null
    } as any;
  }

  return <UserContext.Provider value={defaultAppState}>
    <SetupModeProvider fetchSetupMode={fetchSetupMode}>
      <CoderThemeProvider>
        {component}
      </CoderThemeProvider>
    </SetupModeProvider>
  </UserContext.Provider>
}

PROS:

  • This can be implemented stand-alone, and we can build new UI alongside legacy UI, without impacting coder/m
  • No need for a separate 'components' project that is shared between coder/m and coder/coder

CONS:

  • This necessitates having coder/coder contain a coder/m submodule, which might be the opposite of what is needed for the back-end code.

Comment thread site/match-sorter.d.ts
@@ -0,0 +1,33 @@
declare module "match-sorter" {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

We have a couple of definition files that needed to be picked up to compile the 'v1' modules... If we go with this approach, I'll look for a nicer way to handle this.

Comment thread site/tsconfig.json
"resolveJsonModule": true,
"isolatedModules": true,
"paths": {
"@v1/*": [

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

These paths are important to be able to resolve dependencies correctly for the typescript compiler...

Comment thread site/webpack.config.js
resolve: {
extensions: ['.tsx', '.ts', '.js'],
alias: {
'@v1': path.resolve(__dirname, '..', 'm'),

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

And these aliases and modules are necessary for webpack (or next, on top of webpack) to pick up the nested modules

@bryphe-coder bryphe-coder changed the title experiment: Option 1 - Share v1 UI via coder/m submodule experiment: Frontend - Share v1 UI via coder/m submodule (Approach 1) Jan 5, 2022
@kylecarbs

Copy link
Copy Markdown
Member

This is a pretty interesting way to do it. My primary concern is the coupling from v2 -> v1. Ideally it's the other way around from my perspective.

@bryphe-coder

Copy link
Copy Markdown
Contributor Author

Thanks @kylecarbs !

I'll revisit the approach and focus on a strategy that doesn't need coupling from v2 -> v1, like the one you suggested on Slack - I'll look at pulling in components from v1 (like you've done with the peer package, but for the front-end)

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.

2 participants