Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”

This article has participated in the “Digitalstar Project” and won a creative gift package to challenge the creative incentive money.

preface

According to the order, the last GlowingOverscrollIndicator is analyzed, while the difficulty is not great, but as a Widget, accounted for a lot of itself in the Widget tree;

So remove the relevant parts, the next analysis is: _ScrollableScope

directory

Juejin. Cn/post / 701653…

Same convention, let’s look at annotations, conceptual analysis

However, this time it’s only two lines:

// Enable Scrollable.of() to work as if ScrollableState was an inherited widget.
// ScrollableState.build() always rebuilds its _ScrollableScope.
Copy the code

It’s true, though, that _ScrollableScope itself isn’t complicated — it’s just a dozen lines of code that you can read at a glance, and being an InheritedWidget is all you’re doing: storing shared data;

In this case, the shared data is ScrollableState and ScrollPosition; So the question is, what is storage sharing for?

What the shared data is used for

1. ScrollableState; As you can see, there is only one place where it itself is available:

static ScrollableState? of(BuildContext context) { final _ScrollableScope? widget = context.dependOnInheritedWidgetOfExactType<_ScrollableScope>(); return widget? .scrollable; }Copy the code

Depending on where it is called, this method can be used in one of two ways:

  1. Use the data in the state, or even the state itself, to make some judgments;
  2. Use position and Physics in State to perform some gesture calculations and update the information in position;

2, Another interesting shared data: position again;

So here comes the question:

Why do we need to provide a separate position, just use the position in the above ScrollableState? In other words, is this position different from the position obtained with state above?

I haven’t figured out the answer to this question, but I guess: is it just for convenience? To be reasonable, _ScrollableScope follows the life cycle of ScrollableState, and reconstruction is also rebuilt together. Postion should always be consistent with state, so there is no difference between it;

Anyway, what does this position do?

Remember the interesting lazy loading method mentioned earlier: No, this position is used here:

static bool recommendDeferredLoadingForContext(BuildContext context) { final _ScrollableScope? widget = context.getElementForInheritedWidgetOfExactType<_ScrollableScope>()? .widget as _ScrollableScope? ; if (widget == null) { return false; } return widget.position.recommendDeferredLoading(context); }Copy the code

So much for the analysis of _ScrollableScope itself; We should say that all inheritedWidgets should not be too complicated and provide shared data.

The key is to use these shared data;