surfstudio
diff --git a/‎.DS_Store
-8 KB b/‎.DS_Store
-8 KB
diff --git a/‎.github/workflows/Build.yml
Lines changed: 7 additions & 4 deletions b/‎.github/workflows/Build.yml
Lines changed: 7 additions & 4 deletions
diff --git a/‎.gitignore
Lines changed: 2 additions & 0 deletions b/‎.gitignore
Lines changed: 2 additions & 0 deletions
diff --git a/‎.swift-version
Lines changed: 1 addition & 1 deletion b/‎.swift-version
Lines changed: 1 addition & 1 deletion
diff --git a/‎CHANGELOG.md
Lines changed: 25 additions & 0 deletions b/‎CHANGELOG.md
Lines changed: 25 additions & 0 deletions
diff --git a/‎Documentation/ContributingGuide.md
Lines changed: 45 additions & 0 deletions b/‎Documentation/ContributingGuide.md
Lines changed: 45 additions & 0 deletions
diff --git a/‎Documentation/Entities.md
Lines changed: 292 additions & 0 deletions b/‎Documentation/Entities.md
Lines changed: 292 additions & 0 deletions
@@ -1,6 +1,11 @@
 name: Build
 
-on: [pull_request]
+on:
+  push:
+    branches:
+      - master
+      - develop
+  pull_request:
 
 jobs:
   build:
@@ -10,8 +15,6 @@ jobs:
     - name: Build
       run: xcodebuild -target ReactiveDataDisplayManager
     - name: Run tests
-      run: xcodebuild test -scheme ReactiveDataDisplayManager -configuration "Debug" -sdk iphonesimulator -enableCodeCoverage YES -destination 'platform=iOS Simulator,name=iPhone 8,OS=13.2' | xcpretty -c
+      run: xcodebuild test -scheme ReactiveDataDisplayManager -configuration "Debug" -sdk iphonesimulator -enableCodeCoverage YES -destination 'platform=iOS Simulator,name=iPhone 8' | xcpretty -c
     - name: Upload Coverage
       run: bash <(curl -s https://codecov.io/bash) -J 'ReactiveDataDisplayManager'
-    
-
 
@@ -67,3 +67,5 @@ fastlane/screenshots
 fastlane/test_output
 Example/Pods
 Podfile.lock
+.DS_Store
+.bundle/
@@ -1 +1 @@
-3.0
+5.0
@@ -0,0 +1,25 @@
+## 7.0.0 Refactoring
+### Added
+- `Animator` protocol to isolate deprecated `begin/end updates`
+- `PluginAction` protocol to handle simple actions with collection events
+- `FeaturePlugin` protocol to extend collection manager with features quickly
+- `CollectionBuilder` struct to build `CollectionManager`
+- `TableBuilder` struct to build `TableManager`
+- `rddm` namespace to quick access to manager builders
+
+### Updated
+
+- required `var view: CollectionType!` of `DataDisplayManager` protocol instead of required constructor
+- abstract `Delegate` and `DataSource` is properties of `DataDisplayManager`
+
+### Deprecated
+
+- `BaseTableDataDisplayManager` class replaced with `ManualTableManager`
+- `PaginableBaseTableDataDisplayManager` class will be removed at **7.1.**. Use `TableLastCellIsVisiblePlugin` instead.
+- `ExtendableBaseTableDataDisplayManager` class will be removed at **7.1**. Part of `BaseTableManager` now.
+- `GravityTableDataDisplayManager` class replaced with `GravityTableManager`
+- `FoldingTableDataDisplayManager` class will be removed at **7.1.**. Use `TableFoldablePlugin` instead.
+- `GravityFoldingTableDataDisplayManager` class will be removed at **7.1.**. Use composition of `GravityTableManager` and `TableFoldablePlugin`
+- `SizableCollectionDataDisplayManager` class will be removed at **7.1.**. Part of `BaseCollectionManager`
+- `BaseCollectionDataDisplayManager` replaced with `BaseCollectionManager`
+- `SelectableItem`, `DisplayableFlow`, `MovableGenerator` and other item protocols will be removed at **7.1.**. Replaced with `{ability}ableItem` for example `SelectableItem`
@@ -0,0 +1,45 @@
+# Contributing guide
+
+Thank you for your help! Before you start, let's take a look at some agreements.
+
+## Versioning
+
+Version format is `x.y.z` where
+- x is major version number. Bumped only in major updates (implementaion changes, adding new functionality)
+- y is minor version number. Bumped only in minor updates (interface changes)
+- z is minor version number. Bumped in case of bug fixes and e.t.c.
+
+## Branch name
+
+We are developing with minimal Git-flow.
+Base your branch from `develop` and select name with one from pattern
+
+- bugfix/{issue_number}/{description} - for fixing small issues
+- feature/{issue_number}/{description} - for adding new functionality
+- hotfix/{description} - for fixing very small issues without discovered issues (like fixing unit tests, fixing typo etc)
+
+## Pull request rules
+
+Make sure that your code:
+
+- [ ]	Does not contain errors
+- [ ]	New functionality is covered by tests and new functionality passes old tests
+- [ ]	Create example that demonstrate new functionality if it is possible
+
+## Accepting the changes
+
+After your pull request passes the review code, the project maintainers will merge the changes
+into the branch to which the pull request was sent.
+
+## Issues
+
+Feel free to report any issues and bugs.
+
+1.	To report about the problem, create an issue on GithHub
+2.	In the issue add the description of the problem
+3.	Do not forget to mention your development environment, Xcode version, iOS version, frameworks required for
+    illustration of the problem
+4.	It is necessary to attach the code part that causes an issue or to make a small demo project
+    that shows the issue
+5.	Attach stack trace so it helps us to deal with the issue
+6.	If the issue is related to layout or animation, screen recording is required
@@ -0,0 +1,292 @@
+# Entities overview
+
+Basically `DataDisplayManager` contains such set of entities.
+
+[![AbstractDataDisplayManager](https://i.ibb.co/rH9Kkp6/Abstract-Data-Display-Manager.png)](https://ibb.co/TtyDc08)
+
+To simplify explanation of entities relationships we can mark each entity with atomic architecture terms.
+
+[![Atomic Architecture](https://i.ibb.co/3cMwnjZ/2021-02-20-18-52-59.png)](https://ibb.co/L1JM3c7)
+
+Greater component is more complex, and can directly or indirectly operate with smaller components.
+
+**RECOMMENDATION** Interact, customize or extend atoms and moleculas when it possible and not greater entities.
+
+## DataDisplayManager
+
+`DataDisplayManager` protocol it is main *template* with client interface which operating with `generators`.
+
+Concrete implementation with injected plugins is *page* in atomic terms.
+
+### Example
+
+In base implementation you can only add `generators` and reload collection.
+
+But if your collection can change size dynamically, you need to choose between `Manual` and `Gravity` manager.
+
+Assume you have such screen with two cells and horizontal scrolling content
+```
+Screen:
+  Cell A:
+    - item 1
+    - item 2
+    ...
+  Cell B:
+    - item 1
+    - item 2
+    ...
+```
+
+Each cell content is loading from separate endpoint. It means that sometimes cell A can be loaded first, and sometimes cell B. But cells order should always be the same.
+
+Should we always wait loading of both sections before layout?
+
+No
+
+With `manual` approach
+
+```swift
+
+private lazy var ddm = tableView.rddm.manualBuilder.build()
+
+private var generatorA: TableCellGenerator?
+private var generatorB: TableCellGenerator?
+
+func onContentALoaded(items: [ItemA]) {
+
+  let generatorA = GeneratorA(items: items)
+
+  if let generatorB = self.generatorB {
+    ddm.insert(before: generatorB, new: [generatorA])
+  } else {
+    ddm.addCellGenerator(generatorA)
+    ddm.forceRefill()
+  }
+
+  self.generatorA = generatorA
+}
+
+func onContentBLoaded(items: [ItemB]) {
+
+  let generatorB = GeneratorB(items: items)
+
+  if let generatorA = self.generatorA {
+    ddm.insert(after: generatorA, new: [generatorB])
+  } else {
+    ddm.addCellGenerator(generatorB)
+    ddm.forceRefill()
+  }
+
+  self.generatorB = generatorB
+}
+
+```
+
+With `gravity` approach
+
+```swift
+
+private lazy var ddm = tableView.rddm.gravityBuilder.build()
+
+func onContentALoaded(items: [ItemA]) {
+  let generatorA = GeneratorA(items: items)
+  ddm.addCellGenerator(generatorA)
+  ddm.forceRefill()
+}
+
+func onContentBLoaded(items: [ItemB]) {
+  let generatorB = GeneratorB(items: items)
+  ddm.addCellGenerator(generatorB)
+  ddm.forceRefill()
+}
+
+```
+
+Secret in generators. Each `GravityGenerator` has property heaviness. This allow us to forget about sort order on fill stage.
+
+In this example you can see differences between managing approaches and choose one for your needs.
+
+`Manual` approach will be more useful in simple collections or when you updating cells based on user actions, like tap on plus button inside specific cell..
+
+## Generator
+
+- *Atom*
+- Can build cells
+- Can configure cells
+- Can store closures or current cell state
+- Stored inside `DataDisplayManager` and can cached to directly update concrete cell
+
+`BaseCellGenerator` is your choice if you need display cell and process selection event.
+
+This is generic generator with only one requirement to cell - conforming to `ConfigurableItem` protocol.
+
+Recommended way to create generator `YourCellType.rddm.baseGenerator(with: model)` where model is `ConfigurableItem.Model` instance.
+
+**NOTE** If you want store closures, current cell state or extend generator with some protocol, preferable extending `BaseCellGenerator` and not create your own.
+
+### Example
+
+Extending `BaseCellGenerator` to `FoldableItem`
+
+```swift
+final class FoldableCellGenerator: BaseCellGenerator<FoldableTableViewCell>, FoldableItem {
+
+    // MARK: - FoldableItem
+
+    var didFoldEvent = BaseEvent<Bool>()
+    var isExpanded = false
+    var childGenerators: [TableCellGenerator] = []
+
+    // MARK: - Configuration
+
+    override func configure(cell: FoldableTableViewCell, with model: FoldableTableViewCell.Model) {
+        super.configure(cell: cell, with: model)
+
+        didFoldEvent.addListner { isExpanded in
+            cell.update(expanded: isExpanded)
+        }
+    }
+
+}
+```
+
+### Errors
+
+- `Could not load NIB in bundle ... with name 'YourCellName'`
+This error appears because you are using class based cells (not UINib), but inside RDDM cells registering via UINib.
+
+  **Your should override default registering in generator**
+```swift
+extension YourCellGenerator: TableCellGenerator {
+  // ...
+
+  func registerCell(in tableView: UITableView) {
+      tableView.register(identifier, forCellReuseIdentifier: String(describing: identifier))
+  }
+
+  // ...
+}
+```
+
+or simply fix initialising of your BaseGenerator using ` BaseCellGenerator.init(with: Cell.Model, registerType: .class)`
+
+## Delegate
+
+- *Organism*
+- based on `UITableViewDelegate` or `UICollectionViewDelegate` (depends on collection type)
+- Proxy collection events to plugins
+
+### How to change
+
+We hope, that bult-in delegate will cover 99% of your needs.
+
+Btw you always can replace delegate with your own implementation.
+
+**DO NOT FORGET** inherit BaseDelegate or add calls to plugins to not loose bult-in features.
+
+`tableView.rddm.baseBuilder.set(delegate: YourCustomDelegate()).build()`
+
+## DataSource
+
+- *Organism*
+- Based on `UITableViewDataSource` or `UICollectionViewDataSource` (depends on collection type)
+- Implement `UITableViewDataSourcePrefetching` or `UICollectionViewDataSourcePrefetching` (depends on collection type)
+- Proxy collection events to plugins
+
+### How to change
+
+We hope, that bult-in datasource will cover 99% of your needs.
+
+Btw you always can replace datasource with your own implementation.
+
+**DO NOT FORGET** inherit BaseDataSource or add calls to plugins to not loose bult-in features.
+
+`tableView.rddm.baseBuilder.set(dataSource: YourCustomDataSource()).build()`
+
+## PluginAction
+
+- *Molecula*
+- is represent reaction on collection event or events.
+- Have access to manager. It means, that you have access to generators and can update collection from plugin.
+- Injected in `PluginCollection` - simple list wrapper. It means, that on **each** event we can have **many** reactions (plugin-actions).
+- can not return values to delegate or datasource
+
+You can look at full list of proxy events in enums: `TableEvent`, `PrefetchEvent`, `CollectionEvent`, `ScrollEvent`.
+
+### How to add
+
+Simply add plugin in stage of building
+
+`tableView.rddm.baseBuilder.add(plugin: YourCustomPlugin()).build()`
+
+And conform generator to concrete `PluginAction.GeneratorType`
+
+### Example
+
+Handling rows selection.
+
+```swift
+public class TableSelectablePlugin: BaseTablePlugin<TableEvent> {
+
+    typealias GeneratorType = SelectableItem
+
+    public override init() {}
+
+    public override func process(event: TableEvent, with manager: BaseTableManager?) {
+
+        switch event {
+        case .didSelect(let indexPath):
+            guard let selectable = manager?.generators[indexPath.section][indexPath.row] as? GeneratorType else {
+                return
+            }
+            selectable.didSelectEvent.invoke(with: ())
+
+            if selectable.isNeedDeselect {
+                manager?.view?.deselectRow(at: indexPath, animated: true)
+            }
+        default:
+            break
+        }
+    }
+
+}
+```
+
+More examples in bult-in plugins and example project.
+
+## FeaturePlugin
+
+- *Molecula*
+- is implement part of delegate, datasource or both
+- injected as **one** optional instance to avoid conflicts
+- can return values to delegate or datasource
+
+Basically this entity is adding fixed part of functionality like moving or dragging of cells.
+
+### How to add
+
+Simply set plugin in stage of building
+
+`tableView.rddm.baseBuilder.add(featurePlugin: YourCustomPlugin()).build()`
+
+And conform generator to concrete `FeaturePlugin.GeneratorType`
+
+### Examples
+
+Look at `TableMovablePlugin`, `TableSectionTitleDisplayablePlugin` or `TableSwipeActionsConfigurationPlugin` and analogs for `UICollectionView`.
+
+## Animator
+
+Little atom created for approaches to animate collection changes.
+
+`TableUpdatesAnimator` uses **beginUpdates/endUpdates** approach which will be deprecated soon.
+
+`TableBatchUpdatesAnimator` uses **performBatchUpdates** approach which available since iOS 11.
+
+Animator is selected based on iOS version, so most likely you never need to change this entity, but we've save such ability for you.
+
+### How to change
+
+Implement protocol `Animator` and set your implementation in builder
+
+`tableView.rddm.baseBuilder.set(animator: YourCustomAnimator()).build()`