WidgetKit extensions

[filip-zielinski-intive]

I'm implementing WidgetKit extension and trying to apply the architecture for it, but don't see how to do this properly. Widget is described the following way:

struct MyWidget: Widget {
    let kind: String = "MyWidget"

    var body: some WidgetConfiguration {
        StaticConfiguration(
            kind: kind,
            provider: MyProvider()
        ) { entry in
            MyWidgetEntryView(
                store: Store(
                    initialState: AppState(entry: entry),
                    reducer: appReducer,
                    environment: AppEnvironment()
                )
            )
        }
        .configurationDisplayName("My Widget")
        .description("This is my widget.")
    }
}

where MyProvider conforms to TimelineProvider protocol:

struct MyProvider: TimelineProvider {

    func placeholder(in context: Context) -> MyTimelineEntry {
        MyTimelineEntry()
    }

    func getSnapshot(
        in context: Context,
        completion: @escaping (MyTimelineEntry) -> Void
    ) {
        let entry = MyTimelineEntry()
        completion(entry)
    }

    func getTimeline(
        in context: Context,
        completion: @escaping (Timeline<RecentTeasTimelineEntry>) -> Void
    ) {
        // load entries asynchronously

       let timeline = Timeline(
            entries: [entries],
            policy: .after(nextUpdateDate)
        )
       completion(timeline)
    }
}

I assume MyProvider should be made a part of AppEnvironment. If I understand correctly, instead of loading data inside the callback getTimeline it is better to do this in appReducer by running an effect. The problem is I don't see how to be notified
that data loading should be performed, cause there are no connections between appReducer and MyProvider at the moment. Moreover, TimelineProvider protocol requires the relevant completion to be invoked, wouldn't it be a problem to do this in a reducer when data is loaded?

Generally speaking, I don't understand how to build an infrastructure for this use case. Any ideas? Thanks in advance.

[mbrandonw]

Hi @filip-zielinski-intive, this is an interesting question, and we don't currently have much info on it. We should probably add a case study soon.

First, we do not think it's appropriate to add MyProvider to the environment. Only things that are easy to mock for tests should be put into the environment, and I don't think MyProvider fits the bill.

Second, you can pass the view store to MyProvider so that it is capable of sending actions and reading state:

struct MyWidget: Widget {
  let kind: String = "MyWidget"
  let store = Store(...)
  var body: some WidgetConfiguration {
    StaticConfiguration(
      kind: kind,
      provider: MyProvider(viewStore: ViewStore(self.store))
    ) {
      ...
    }
  }
}

struct MyProvider: TimelineProvider {
  let viewStore: ViewStore<AppState, AppAction>

  ...
}

Note that the view store is held as a let instead of an @ObservedObject because we don't need the provide to actually observe state (and in fact, AFAIK, @ObservedObject does not do anything inside a timeline provider).

Next, you can send actions to the view store whenever one of the provider's endpoints is called, and then read the state. This works because viewStore.send does it's work synchronously, so you can read the newest state immediately after sending an action.

So, for example, in the placeholder method, if you wanted that logic to be handled by the reducer, you could add a MyTimelineEntry to your state and an action for when the system calls the placeholder method:

func placeholder(in context: Context) -> MyTimelineEntry {
  viewStore.send(.timelineProviderRequestsPlaceholder)
  return viewStore.timelinePlaceholder
}

This works nicely because you don't need to perform any effects in order to construct the placeholder.

The getSnapshot and getTimeline are a bit more complicated since they are asynchronous. Again you will want to hold onto the timeline state in your state, and add an action for each timeline method, but the question is how do you wait for your effects to finish so that you can read the state:

func getSnapshot(
  in context: Context,
  completion: @escaping (MyTimelineEntry) -> Void
) {
  viewStore.send(.timelineProviderRequestsSnapshot)

  // wait for effect to finish and invoke completion 
  // with data from the view store???
}

Soon we will actually have a really nice way to accomplish this using some new concurrency tools we are adding to the library that allow you to await until the effects finish from sending an action:

func getSnapshot(
  in context: Context,
  completion: @escaping (MyTimelineEntry) -> Void
) {
  Task {
    await viewStore.send(.timelineProviderRequestsSnapshot).finish()
    completion(viewStore.timelineSnapshot)
  }
}

Until then you can still accomplish this, but just in a slightly less ergonomic way. There's a method called send(while:) that allows you to suspend until the view store's state satisfies a predicate. This requires you to maintain some extra state, such as an isLoading boolean:

func getSnapshot(
  in context: Context,
  completion: @escaping (MyTimelineEntry) -> Void
) {
  Task {
    await viewStore.send(.timelineProviderRequestsSnapshot, while: \.isLoading)
    completion(viewStore.timelineSnapshot)
  }
}

You must make sure to set isLoading to true in the reducer when the effect starts and set it back to false when the effect finishes.

Or you can hold onto timelineSnapshot as an optional, but then you have to remember to clean up the state after by sending another action:

func getSnapshot(
  in context: Context,
  completion: @escaping (MyTimelineEntry) -> Void
) {
  Task { 
    await viewStore.send(.timelineProviderRequestsSnapshot, while: { $0.timelineSnapshot == nil })
    completion(viewStore.timelineSnapshot)
    viewStore.send(.timelineSnapshotFinished)
  }
}

That's the rough idea at least. Good luck!

[Bartozo]

Just wanted to mention that the reducer will be reused across all the widgets, since the store is provided to the Provider as an argument. This behavior can lead to unintended data overlap among widgets, especially if each widget requires its own isolated state.

Are you planning to make a case study for this topic?