Skip to content

fix(ui): make internet resource off by default#6518

Merged
conectado merged 20 commits intomainfrom
fix/internet-resource-ui
Sep 4, 2024
Merged

fix(ui): make internet resource off by default#6518
conectado merged 20 commits intomainfrom
fix/internet-resource-ui

Conversation

@conectado
Copy link
Contributor

@conectado conectado commented Aug 31, 2024

With this PR we made internet resource disabled by default.

Since no other resource is disalable and internet resource behavior is particular we remove all client code to make non internet resource disalable.

Also, since the portal never makes the internet resource that can't be disabled we remove the whole code path to handle that.

Additionally, some other smaller refactors across the UI wrt internet resource

Fix #6509

@vercel
Copy link

vercel bot commented Aug 31, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
firezone ✅ Ready (Inspect) Visit Preview 💬 Add feedback Sep 4, 2024 4:56pm

@github-actions
Copy link

github-actions bot commented Sep 2, 2024

🐰Bencher

ReportWed, September 4, 2024 at 17:05:40 UTC
ProjectFirezone
Branchfix/internet-resource-ui
Testbedgithub-actions
Click to view all benchmark results
BenchmarkThroughputThroughput Results
bits/s | (Δ%)
Throughput Lower Boundary
bits/s | (%)
direct-tcp-client2server✅ (view plot)249,081,454.61 (+1.02%)238,104,360.87 (95.59%)
direct-tcp-server2client✅ (view plot)255,825,452.08 (+1.80%)243,473,768.23 (95.17%)
direct-udp-client2server✅ (view plot)307,110,372.58 (+5.78%)271,090,526.79 (88.27%)
direct-udp-server2client✅ (view plot)398,134,354.69 (-0.90%)388,364,859.09 (97.55%)
relayed-tcp-client2server✅ (view plot)248,353,066.40 (-0.57%)240,321,338.22 (96.77%)
relayed-tcp-server2client✅ (view plot)262,640,789.51 (+1.18%)249,878,775.24 (95.14%)
relayed-udp-client2server✅ (view plot)227,793,889.73 (-1.84%)220,878,630.63 (96.96%)
relayed-udp-server2client✅ (view plot)362,181,036.15 (+7.27%)316,663,607.09 (87.43%)

Bencher - Continuous Benchmarking
View Public Perf Page
Docs | Repo | Chat | Help

Copy link
Member

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM

}
}

fun Resource.toViewResource(resourceState: ResourceState): ViewResource {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a ctor on ViewResource would be more natural.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like to do the conversion as resource.toResourceViewModel instead of ResourceViewModel.from(...) and pass the resource in.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. My reasoning would be that if you think in terms of dependencies, then the view-stuff is okay to know about the actual entities but the entities shouldn't know about the view. Like, if you were to extract the view into a separate module / crate then you can only do that if the conversion function lives on the view-model type (or completely independent of both).

Comment on lines +26 to +40
fun internetResourceDisplayName(resource: Resource, state: ResourceState): String {
return if (!resource.canBeDisabled) {
"$OnSymbol ${resource.name}"
} else {
"${state.stateSymbol()} ${resource.name}"
}
}

fun displayName(resource: Resource, state: ResourceState): String {
if (resource.isInternetResource()) {
return internetResourceDisplayName(resource, state)
} else {
return resource.name
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd expect utilities to be below the function that uses them.

let internet_resource = self
.status
.internet_resource()
.ok_or(anyhow!("Tunnel not ready"))?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.ok_or(anyhow!("Tunnel not ready"))?;
.context("Tunnel not ready")?;

conectado and others added 6 commits September 3, 2024 22:44
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
conectado and others added 11 commits September 3, 2024 22:44
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Comment on lines +45 to +49
return if (this.isEnabled()) {
ResourceState.DISABLED
} else {
ResourceState.ENABLED
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are these reversed? Seems a tad confusing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this function "toggles" it so it swap the state out

Comment on lines +18 to +19
public const val ON_SYMBOL: String = "<->"
public const val OFF_SYMBOL: String = " — "
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these be defined on the companion object at the bottom?

Also I think public might be redundant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these be defined on the companion object at the bottom?

Is there any benefit to that? Also, shouldn't in that case be a companion to ResourceState?

return "${state.stateSymbol()} ${resource.name}"
}

fun Resource.toResourceViewModel(resourceState: ResourceState): ResourceViewModel {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this function be defined on the Resource class?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's defined in the Resource class but not on the Resource module.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I converted this to a constructor on ResourceViewModel

Comment on lines +82 to +84
tunnelService?.internetResourceToggled(internetState().toggle())
refreshList()
Log.d(TAG, "Internet resource toggled ${internetState()}")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Next two lines only make sense to execute if the tunnelService is valid, no?

Suggested change
tunnelService?.internetResourceToggled(internetState().toggle())
refreshList()
Log.d(TAG, "Internet resource toggled ${internetState()}")
tunnelService?.let {
it.internetResourceToggled(internetState().toggle())
refreshList()
Log.d(TAG, "Internet resource toggled ${internetState()}")
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there any point at which this can actually happen to be nil? Maybe I just use !!?

@conectado conectado added this pull request to the merge queue Sep 4, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 4, 2024
@conectado conectado added this pull request to the merge queue Sep 4, 2024
Merged via the queue into main with commit 700b056 Sep 4, 2024
@conectado conectado deleted the fix/internet-resource-ui branch September 4, 2024 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Internet Resource client UX iteration

3 participants