przemek-jablonski / polaris Goto Github PK

MVVM architecture has a few base protocols, such as ViewModel or Interactor. Obviously, if the target project doesn't have them created, then the compilation will fail.

In order to support quick project creation with Polaris (and not only generating new screens in existing one) there needs to be an option (preferably as a checkbox in Screen.xctemplate) to generate base protocols as well.

Screen.xctemplate needs to be split into modular subtemplates (___FILEBASENAME___Assembly.swift, ___FILEBASENAME___Interactor.swift etc) which will be in turn integrated as Ancestors. This has to be done in order to minimise maintenance cost over time.

Although using Polaris requires user input to describe app name and new screen name, those informations are not used to create an actual folder (or group in Xcode nomenclature) where the code will be put. This forces user to create one manually (to maintain clean folder structure in project), but it should be done automatically

Solution:

PreviewProviders need to be generated with init method where there will be NSBatchDeleteRequest performed (commented out, obviously, because the type of faked data is unknown at the generation time - it is supposed to be a quick hint)

Introduce RenderingModels (ViewModels), which will enable to:

• generate stubs, mocks and func/vars for the architecture components where *RenderingModel is actually used
• Swiftui mocks will become easier
• fetching Context will be removed from Swiftui PreviewProvider
• new file with prefixed architecture components

In order to generate dependency injection graph, Swinject-based projects need to have:

• Assembler instance
• Assembler enum static wrapper
• Assembler registration in AppDelegate, WatchKitDelegate
• assembly for common definitions (CommonAssembly)

In order to support quick project creation with Polaris (and not only generating new screens in existing one) there needs to be an option (preferably as a checkbox in Screen.xctemplate) to generate aforementioned DI architecture as well.

Right now randomized background color for newly generated View is being calculated every time view is initialized. This looks whack when there's multiple previews going on for single PreviewProvider.

Because Views and Subviews should be exclusive content for given platform-target, having aliases + models in the same file makes it impossible to test (include in iOS unit testing bundle)

Right now there is a custom PreviewProvider generated for every SwiftUI view, which displays previews from multiple devices (using Group and .preview(on:)modifiers).

This is very good except devices used in preview(on:) need to be unique and derived from the deployment platform (view generated for ios should use ios-based preview devices etc.). Currently every view is previewed on applewatch_old, applewatch_large and applewatch_small, which is incorrect if creating template for, let's say, appletvos.

public, struct/class, import Foundation and name of the class (derived from the file name) should be automatically provided. It's 2020 after all.