Foundry376/Mailspring
1
1
Fork 0
mirror of https://github.com/Foundry376/Mailspring.git synced 2024-11-14 05:41:05 +08:00
Code Issues Projects Releases Packages Wiki Activity
Mailspring/internal_packages/account-sidebar/lib/components/account-sidebar.cjsx

49 lines
1.2 KiB
Text
Raw Normal View History

AccountSidebar package refactor: - Creates OutlineView generic component and uses that instead of custom code - Refactors AccountSidebarStore: - Split the generation of the state tree into smaller functions - Adds different types of account sidebar items and sections, which contain logic and props necessary to be rendered as OutlineViewItems, and removes that logic from the store - Removes WorkspaceStore.SidebarItem and removes the ability to register new sidebar items. If people want to add something to the sidebar they can just register a Component via the component registry and use the OutlineView component - Removes the DraftListSidebarItem, which was basically duplicated code for an item but with a different data source. This is now handled generically by the account sidebar by rendering OutlineViewItems with different props and handlers - Clean ups here and there: - TODO - Add AccountSwitcher - Revisit calculation and generation of the state tree. Should the parent store contain and update the entire state all the time. Should separate items inside the tree have their own data sources? - This would avoid having the AccountSidebarStore listen to a bunch of different other stores, and the specific logic wold be contained inside each item type.
2016-01-16 08:27:57 +08:00
_ = require 'underscore'
Minor fixes and style updates
2016-01-19 03:39:53 +08:00
React = require 'react'
AccountSidebar package refactor: - Creates OutlineView generic component and uses that instead of custom code - Refactors AccountSidebarStore: - Split the generation of the state tree into smaller functions - Adds different types of account sidebar items and sections, which contain logic and props necessary to be rendered as OutlineViewItems, and removes that logic from the store - Removes WorkspaceStore.SidebarItem and removes the ability to register new sidebar items. If people want to add something to the sidebar they can just register a Component via the component registry and use the OutlineView component - Removes the DraftListSidebarItem, which was basically duplicated code for an item but with a different data source. This is now handled generically by the account sidebar by rendering OutlineViewItems with different props and handlers - Clean ups here and there: - TODO - Add AccountSwitcher - Revisit calculation and generation of the state tree. Should the parent store contain and update the entire state all the time. Should separate items inside the tree have their own data sources? - This would avoid having the AccountSidebarStore listen to a bunch of different other stores, and the specific logic wold be contained inside each item type.
2016-01-16 08:27:57 +08:00
{OutlineView, ScrollRegion} = require 'nylas-component-kit'
More account sidebar refactor + sections for unified inbox - Refactors some of the old code which was :hankey: - Makes SidbarSection a factory for different types of items for the OutlineView - Decided not to create a OutlineViewItem.Model class since the only purpose it would serve would be to validate getters for props or for documentation, both of which are already done via React.PropTypes. - Adds sections when looking at unified inbox and integrates with new mailbox perspecitve interface - Updates OutlineViewItem a bit + styles - Tests missing
2016-01-19 15:18:19 +08:00
SidebarStore = require '../sidebar-store'
AccountSidebar package refactor: - Creates OutlineView generic component and uses that instead of custom code - Refactors AccountSidebarStore: - Split the generation of the state tree into smaller functions - Adds different types of account sidebar items and sections, which contain logic and props necessary to be rendered as OutlineViewItems, and removes that logic from the store - Removes WorkspaceStore.SidebarItem and removes the ability to register new sidebar items. If people want to add something to the sidebar they can just register a Component via the component registry and use the OutlineView component - Removes the DraftListSidebarItem, which was basically duplicated code for an item but with a different data source. This is now handled generically by the account sidebar by rendering OutlineViewItems with different props and handlers - Clean ups here and there: - TODO - Add AccountSwitcher - Revisit calculation and generation of the state tree. Should the parent store contain and update the entire state all the time. Should separate items inside the tree have their own data sources? - This would avoid having the AccountSidebarStore listen to a bunch of different other stores, and the specific logic wold be contained inside each item type.
2016-01-16 08:27:57 +08:00
Minor fixes and style updates
2016-01-19 03:39:53 +08:00
AccountSidebar package refactor: - Creates OutlineView generic component and uses that instead of custom code - Refactors AccountSidebarStore: - Split the generation of the state tree into smaller functions - Adds different types of account sidebar items and sections, which contain logic and props necessary to be rendered as OutlineViewItems, and removes that logic from the store - Removes WorkspaceStore.SidebarItem and removes the ability to register new sidebar items. If people want to add something to the sidebar they can just register a Component via the component registry and use the OutlineView component - Removes the DraftListSidebarItem, which was basically duplicated code for an item but with a different data source. This is now handled generically by the account sidebar by rendering OutlineViewItems with different props and handlers - Clean ups here and there: - TODO - Add AccountSwitcher - Revisit calculation and generation of the state tree. Should the parent store contain and update the entire state all the time. Should separate items inside the tree have their own data sources? - This would avoid having the AccountSidebarStore listen to a bunch of different other stores, and the specific logic wold be contained inside each item type.
2016-01-16 08:27:57 +08:00
class AccountSidebar extends React.Component
@displayName: 'AccountSidebar'
@containerRequired: false
@containerStyles:
minWidth: 165
maxWidth: 210
constructor: (@props) ->
@state = @_getStateFromStores()
componentDidMount: =>
@unsubscribers = []
More account sidebar refactor + sections for unified inbox - Refactors some of the old code which was :hankey: - Makes SidbarSection a factory for different types of items for the OutlineView - Decided not to create a OutlineViewItem.Model class since the only purpose it would serve would be to validate getters for props or for documentation, both of which are already done via React.PropTypes. - Adds sections when looking at unified inbox and integrates with new mailbox perspecitve interface - Updates OutlineViewItem a bit + styles - Tests missing
2016-01-19 15:18:19 +08:00
@unsubscribers.push SidebarStore.listen @_onStoreChange
AccountSidebar package refactor: - Creates OutlineView generic component and uses that instead of custom code - Refactors AccountSidebarStore: - Split the generation of the state tree into smaller functions - Adds different types of account sidebar items and sections, which contain logic and props necessary to be rendered as OutlineViewItems, and removes that logic from the store - Removes WorkspaceStore.SidebarItem and removes the ability to register new sidebar items. If people want to add something to the sidebar they can just register a Component via the component registry and use the OutlineView component - Removes the DraftListSidebarItem, which was basically duplicated code for an item but with a different data source. This is now handled generically by the account sidebar by rendering OutlineViewItems with different props and handlers - Clean ups here and there: - TODO - Add AccountSwitcher - Revisit calculation and generation of the state tree. Should the parent store contain and update the entire state all the time. Should separate items inside the tree have their own data sources? - This would avoid having the AccountSidebarStore listen to a bunch of different other stores, and the specific logic wold be contained inside each item type.
2016-01-16 08:27:57 +08:00
componentWillUnmount: =>
unsubscribe() for unsubscribe in @unsubscribers
_onStoreChange: =>
@setState @_getStateFromStores()
_getStateFromStores: =>
More account sidebar refactor + sections for unified inbox - Refactors some of the old code which was :hankey: - Makes SidbarSection a factory for different types of items for the OutlineView - Decided not to create a OutlineViewItem.Model class since the only purpose it would serve would be to validate getters for props or for documentation, both of which are already done via React.PropTypes. - Adds sections when looking at unified inbox and integrates with new mailbox perspecitve interface - Updates OutlineViewItem a bit + styles - Tests missing
2016-01-19 15:18:19 +08:00
standardSection: SidebarStore.standardSection()
userSections: SidebarStore.userSections()
AccountSidebar package refactor: - Creates OutlineView generic component and uses that instead of custom code - Refactors AccountSidebarStore: - Split the generation of the state tree into smaller functions - Adds different types of account sidebar items and sections, which contain logic and props necessary to be rendered as OutlineViewItems, and removes that logic from the store - Removes WorkspaceStore.SidebarItem and removes the ability to register new sidebar items. If people want to add something to the sidebar they can just register a Component via the component registry and use the OutlineView component - Removes the DraftListSidebarItem, which was basically duplicated code for an item but with a different data source. This is now handled generically by the account sidebar by rendering OutlineViewItems with different props and handlers - Clean ups here and there: - TODO - Add AccountSwitcher - Revisit calculation and generation of the state tree. Should the parent store contain and update the entire state all the time. Should separate items inside the tree have their own data sources? - This would avoid having the AccountSidebarStore listen to a bunch of different other stores, and the specific logic wold be contained inside each item type.
2016-01-16 08:27:57 +08:00
More account sidebar refactor + sections for unified inbox - Refactors some of the old code which was :hankey: - Makes SidbarSection a factory for different types of items for the OutlineView - Decided not to create a OutlineViewItem.Model class since the only purpose it would serve would be to validate getters for props or for documentation, both of which are already done via React.PropTypes. - Adds sections when looking at unified inbox and integrates with new mailbox perspecitve interface - Updates OutlineViewItem a bit + styles - Tests missing
2016-01-19 15:18:19 +08:00
_renderUserSections: (sections) =>
sections.map (section) =>
<OutlineView key={section.title} {...section} />
AccountSidebar package refactor: - Creates OutlineView generic component and uses that instead of custom code - Refactors AccountSidebarStore: - Split the generation of the state tree into smaller functions - Adds different types of account sidebar items and sections, which contain logic and props necessary to be rendered as OutlineViewItems, and removes that logic from the store - Removes WorkspaceStore.SidebarItem and removes the ability to register new sidebar items. If people want to add something to the sidebar they can just register a Component via the component registry and use the OutlineView component - Removes the DraftListSidebarItem, which was basically duplicated code for an item but with a different data source. This is now handled generically by the account sidebar by rendering OutlineViewItems with different props and handlers - Clean ups here and there: - TODO - Add AccountSwitcher - Revisit calculation and generation of the state tree. Should the parent store contain and update the entire state all the time. Should separate items inside the tree have their own data sources? - This would avoid having the AccountSidebarStore listen to a bunch of different other stores, and the specific logic wold be contained inside each item type.
2016-01-16 08:27:57 +08:00
render: =>
More account sidebar refactor + sections for unified inbox - Refactors some of the old code which was :hankey: - Makes SidbarSection a factory for different types of items for the OutlineView - Decided not to create a OutlineViewItem.Model class since the only purpose it would serve would be to validate getters for props or for documentation, both of which are already done via React.PropTypes. - Adds sections when looking at unified inbox and integrates with new mailbox perspecitve interface - Updates OutlineViewItem a bit + styles - Tests missing
2016-01-19 15:18:19 +08:00
standardSection = @state.standardSection
userSections = @state.userSections
Minor fixes and style updates
2016-01-19 03:39:53 +08:00
<ScrollRegion className="account-sidebar" >
AccountSidebar package refactor: - Creates OutlineView generic component and uses that instead of custom code - Refactors AccountSidebarStore: - Split the generation of the state tree into smaller functions - Adds different types of account sidebar items and sections, which contain logic and props necessary to be rendered as OutlineViewItems, and removes that logic from the store - Removes WorkspaceStore.SidebarItem and removes the ability to register new sidebar items. If people want to add something to the sidebar they can just register a Component via the component registry and use the OutlineView component - Removes the DraftListSidebarItem, which was basically duplicated code for an item but with a different data source. This is now handled generically by the account sidebar by rendering OutlineViewItems with different props and handlers - Clean ups here and there: - TODO - Add AccountSwitcher - Revisit calculation and generation of the state tree. Should the parent store contain and update the entire state all the time. Should separate items inside the tree have their own data sources? - This would avoid having the AccountSidebarStore listen to a bunch of different other stores, and the specific logic wold be contained inside each item type.
2016-01-16 08:27:57 +08:00
<div className="account-sidebar-sections">
More account sidebar refactor + sections for unified inbox - Refactors some of the old code which was :hankey: - Makes SidbarSection a factory for different types of items for the OutlineView - Decided not to create a OutlineViewItem.Model class since the only purpose it would serve would be to validate getters for props or for documentation, both of which are already done via React.PropTypes. - Adds sections when looking at unified inbox and integrates with new mailbox perspecitve interface - Updates OutlineViewItem a bit + styles - Tests missing
2016-01-19 15:18:19 +08:00
<OutlineView {...standardSection} />
{@_renderUserSections(userSections)}
AccountSidebar package refactor: - Creates OutlineView generic component and uses that instead of custom code - Refactors AccountSidebarStore: - Split the generation of the state tree into smaller functions - Adds different types of account sidebar items and sections, which contain logic and props necessary to be rendered as OutlineViewItems, and removes that logic from the store - Removes WorkspaceStore.SidebarItem and removes the ability to register new sidebar items. If people want to add something to the sidebar they can just register a Component via the component registry and use the OutlineView component - Removes the DraftListSidebarItem, which was basically duplicated code for an item but with a different data source. This is now handled generically by the account sidebar by rendering OutlineViewItems with different props and handlers - Clean ups here and there: - TODO - Add AccountSwitcher - Revisit calculation and generation of the state tree. Should the parent store contain and update the entire state all the time. Should separate items inside the tree have their own data sources? - This would avoid having the AccountSidebarStore listen to a bunch of different other stores, and the specific logic wold be contained inside each item type.
2016-01-16 08:27:57 +08:00
</div>
</ScrollRegion>
module.exports = AccountSidebar
Reference in a new issue Copy permalink