Open galvesribeiro opened 6 years ago
To give an idea, I had to make a hack like this: https://github.com/BlazorExtensions/SignalR/blob/master/src/Blazor.Extensions.SignalR/HttpConnectionOptions.cs#L17-L21 while that could be avoided if that was internal
.
+1 I have the same issue
I came here for the same issue. In fact, I would like to be able to declare JSInvokable on private static methods. There are parts of my C# framework that I don't want executed from anywhere except javascript.
[JSInvokable(OnPageLoadedId)]
private static void OnPageLoaded()
{
PageLoaded?.Invoke(null, EventArgs.Empty);
}
Ping
I don't think there is any way to be sure that your internal methods are called only by js from your lib. You could use an Observer pattern : a public class publish an event (called by js interop) and your internal class subscribes to this event.
I don't think there is any way to be sure that your internal methods are called only by js from your lib.
@RemiBou This is not problem, who will call jsinvokable method inside lib can control programmer, what we want is that JsInvokable methods not to be visible/accessible from outside assembly.
Maybe this has no sense.
In case where we have referenced some blazor lib, js execution happens not in referenced lib but in project where it is added, so maybe there is no way to see/invoke/call referenced component's internal methods.
@RemiBou do you mean this?
Yes that's what I meant
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
We should be able to mark
public
methods oninternal
types as[JSInvokable]
since most of the lib developer, like myself, don't want to expose internal types to the end user.I know that there is the idea that
JSInvokable
is inherentlypublic
and that mislead the idea that the types using it should be as well. I also know that you can hide a member withEditorBrowseableAttribute(false)
, but that is just an IDE thing and not truly protecting internal APIs from misuse.So, please consider change the scan logic to also look into
internal
types.Thanks!