Fixing a possible null pointer exception and removing unnecessary nullability for settings#99
Conversation
…lability for settings
…to MichaelGHSeg/DefaultStructNPEFix
| return; | ||
| } | ||
|
|
||
| Settings settings = await plugin.Analytics.SettingsAsync(); |
There was a problem hiding this comment.
I know this is already merged but since you already fetch
System system = await analytics.Store.CurrentState<System>();
isn't it redundant to call SettingsAsync which calls
System system = await Store.CurrentState<System>();
return system._settings;
So you can only fetch system, and then on line 173 pass through system._settings.
I don't think it will be much of a performance difference, but it will remove an extra call to Store.CurrentState, which I assume is not cached?
There was a problem hiding this comment.
it is cached in memory, but that's a good call out! the call to SettingsAsync is redundant. we can get ride of it in the next release. thanks for pointing this out!
There was a problem hiding this comment.
I did consider it, but I like having the consolidated interface for settings retrieval. Then we have one place to change it in the future, etc. Or even just for debug breakpoints.
There was a problem hiding this comment.
I mean, if it's cached then it's not a performance impact.
The other thing is - how likely do you think a change for fetching settings will occur?
Either way, I only see two calls to SettingsAsync, one of which is the call here and the other being a call that converts sync-to-async which is only mentioned in the Tests project.
There is no Settings-related logic here honestly, since you just fetch them "automagically" through the System struct.
3 participants
No description provided.