Extract content logic to config from lock screen widget

[tzef]

This is the PR for extracting the parameters used in the stats widget into configs

1. Add new feature flag for lock screen widgets in Jetpack  #20309 (✅ Approved)
2. Implement lock screen widgets UI #20312 (✅ Approved)
3. Add dynamic type support #20342 (TBD)
4. Add localizable string for "Views Today" title #20353 (✅ Approved)
5. [BugFix] Fix widget of home screen for WordPress disappeared #20371 (✅ Approved)
6. Extract content logic to config from lock screen widget #20317 (✅ Approved) 👈 you're here!
7. Create a standalone TimeLineProvider and TimelineEntry for the lock screen  #20368 (✅ Approved)
8. Implement view for logged-out, no-site, and no-data status #20399 (✅ Approved)
9. Notify to reload the timelines for lock screen widget #20405 (✅ Approved)
   (Confirm the data display on UI correctly in this phase)
10. Implement event tracking for the new lock screen widget  #20422 (✅ Approved)
11. Disable lockScreenWidget feature flag #20427 (In Reviewing)

Description

Extract the content logic from LockScreenStatsWidget to the config LockScreenStatsWidgetConfig.
config and widget is 1-1 relationship, added LockScreenTodayViewsStatWidgetConfig for Today Views widget

This will allow for adding new widgets in the future by simply creating another config to provide to LockScreenStatsWidget, without duplicating another widget.

Note:
To achieve this, we have to inject the config to LockScreenStatsWidget.
but LockScreenStatsWidget conforms to the Widget protocol, which requires the implementation of init().

So I added fatalError and deprecated annotation to init() to avoid a force unwrap for the config in LockScreenStatsWidget.
This will cause the compiler to stop the incorrect construction with an error message:
"'init()' is deprecated: replaced by 'init(config:)'".

    private let config: T

    init(config: T) {
        self.config = config
    }

    @available(*, deprecated, renamed: "init(config:)")
    init() {
        fatalError("Please use init(config: SingleStatWidgetConfig) to provide the config")
    }

Diagram

Testing instructions

This change didn't introduce new features

Regression Notes

1. Potential unintended areas of impact
   Adding a widget to the lock screen and display correctness.

2. What I did to test those areas of impact (or what existing automated tests I relied on)
   The testing instruction in previous PRs

3. What automated tests I added (or what prevented me from doing so)
   N/A

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding unit tests for my changes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[staskus]

I overall agree with this configuration and usage, it makes sense to me:

LockScreenStatsWidget(config: LockScreenTodayViewsStatWidgetConfig())

I'll wait for dependent PRs to be merged so I could review this one cleanly and wouldn't make excessive comments.

[staskus]

It looks like since init() implements fatalError then it can be a constant

Suggested change

	private var config: T!
	private let config: T

[tzef]

Thanks, I don't know this!!
Now the syntax looks makes sense 🙌

[tzef]

Yes, let's focus on the previous PR, after that I will reorg this PR and notify you, thanks

[peril-wordpress-mobile]

	Warnings
⚠️	PR is not assigned to a milestone.

Generated by 🚫 dangerJS

[staskus]

@tzef let me know when you want this reviewed, thanks!

[tzef]

@staskus I just rebased it, this PR is ready for review now, thanks!

[staskus]

@staskus I just rebased it, this PR is ready for review now, thanks!

@tzef Thanks. I'll review it in a bit.

[staskus]

Thanks! No surprises here, it looks as I would've imagined. 👍

Good to see this architecture coming alive. It's a nice split:

• Config for data
• View for UI
• ViewProvider for building views for different states

[staskus]

@tzef merging