Designer Maintainability Refactor Plan Proposal

[go1dfish]

Below is an outline of a new directory/component structure for decrediton and a general refactor
plan to pave the way towards a more maintainable, faster, designer friendly decrediton.

The index components can be thought of as containers.
This is where any component logic will go including connecting to redux.

Any component that is not an index component should (eventually) be simple enough to convert
to straight up functions in this form:

const MyPresentationalComponent = ({ className, ...props }) => (
  <div {...{ className }}>
    ...
  </div>
);

The components marked (styleonly) seem to only exist as a vehicle for Radium's inline styling.

From talking on slack we all want to eventually abandon inline styling.

That means these components can eventually go away and be replaced by solid className use in
the components that currently reference them.

Component Structure

• components
  • views
    • Accounts
      • index (redux)
      • Page
      • Account (Formerly AccountRow)
        • index
        • Row
    • GetStarted
      • index (redux)
      • Page
    • Help
    • History
      • index (redux)
      • Page
    • Home
      • index (redux)
      • Page
    • Receive
      • index (redux)
      • QRCode
      • Page
    • Send
      • index (redux)
      • Page
    • Settings
      • index (redux)
      • Page
    • StakePool (This probably needs a deeper breaking up internally after this initial pass)
      • index (redux)
      • Page
    • TxDetails
  • AgendaCard
  • AgendaClose (styleonly)
  • AgendaOverview
    • index
    • Overview
  • AutoBuyerSwitch
  • Balance (redux)
  • BalanceOverviewInfoButton
  • BalanceOverviewInfoModal
  • ChangePassphraseModal
    • index
    • Modal
  • CopyToClipboardButton (Edit: originally planned to split this but I don't think it's necessary)
  • CreateWalletForm
    • index
    • CreateWallet
    • Continue
  • ErrorScreen
  • Header
    • index (redux)
    • GetStarted
    • Header
  • HelpLink
  • HideShowButton
  • ImportScriptModal
    • index
    • Modal
  • KeyBlueButton
  • ManagePoolsButton
  • MenuLink (styleonly)
  • NewExistingSeedToggle
    • index
    • Toggle
  • NumTicketsInput
  • PassphraseModal
    • index
    • Modal
  • PurchaseTicketInfo
  • PurchaseTicketsInfoButton (styleonly)
  • SeedEntry
    • index
    • Entry
  • ShowError
  • Sidebar
    • index
    • Bar
  • SlateGrayButton (styleonly)
  • TicketsCogs (styleonly)
  • TxHistory
    • MindedTxTable
    • TxRow

First Stage: Initial Reorg

This is a shallow first pass at making the app more maintainable with an eye towards separating
concerns between presentation and logic.

Any component that is marked as being broken into index+other components will be split into
the index component and associated presentation component.

We will not be converting all of the presentational components to the function style in this pass
as I believe that may interfere with Radium.

(Turns out it works fine so will be switching to this style with little to no imperative code in the presentational components.)

Likewise the components that are not converted into index+other components will be left alone.

Second Stage: Radium to CSS

Eliminate Radium, convert inline styles to CSS stylesheets and sane classNames.

Third Stage: Split up/Clean up presentational components

It may make sense to split up presentational components more than is outlined here.

StakePool in particularly needs some cleanup. This will be easier after the switch to CSS

The move to a function style for presentational components can happen in this stage as well:

Fourth Stage: Re-evaluate and consolidate state management through redux/reselect

We build out a JS core of decrediton that centralizes the business logic and becomes primary source of truth for the React components.

Much of the logic that would be in index components at this point would be moved to this
functional core.

This core would be built around redux state management

This would be a good time to move to Immutable.js for managing app state, and a goal of this
app core would be to maintain object identity persistence to aid in rerender reduction.

Fifth Stage: Pure Components/Performance

Once state is consistently managed and immutable, we can take advantage of React.PureComponent
through many of our components to reduce rerender CPU churn. Particularly tables of large data.

[vctt94]

I believe this has been achieved and we can close it.

We still have some refactor we can do to improve and discuss about adding hookers, but I believe it will be better fitted in a new proposal.

Closing this one