You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I have found some contexts are exposed and others aren't. I am requesting this be added to the exports. I found react-router does this by aliasing them with an UNSAFE_ prefix as a practice and I think that is a good idea here.
My use case is niche but I am having to do some lower level black magic with react contexts as part of a framework im creating that uses module federation, and... part of the internals requires registering/being aware of contexts in use.
I have created a patch of this locally but I think this is a small, low effort change that can be upstream'ed.
Below is a git diff of what I have done for a reference of what im requesting.
If you are open to this, LMK what you think about the naming scheme idea and which it should apply to.
Subject: [PATCH] refactor: export all contexts
---
Index: packages/core/src/index.tsx
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/packages/core/src/index.tsx b/packages/core/src/index.tsx
--- a/packages/core/src/index.tsx (revision 0d6d062e73189aa196a5ffbd9a8939134f88bd2d)
+++ b/packages/core/src/index.tsx (revision 94bdc4dd6403736c0bc8265f24af85841f4d5b40)
@@ -60,6 +60,7 @@
ILogData,
LogParams,
} from "./contexts/auditLog/types.js";
+export { AuditLogContext } from "./contexts/auditLog/index.js";
export {
AuthActionResponse,
@@ -74,6 +75,10 @@
PermissionResponse,
SuccessNotificationResponse,
} from "./contexts/auth/types.js";
+export {
+ AuthBindingsContext,
+ LegacyAuthContext,
+} from "./contexts/auth/index.js";
export {
ConditionalFilter,
@@ -132,6 +137,7 @@
ValidationErrors,
VariableOptions,
} from "./contexts/data/types.js";
+export { DataContext } from "./contexts/data/index.js";
export {
I18nContext,
@@ -156,6 +162,7 @@
LiveProvider,
LiveListParams,
} from "./contexts/live/types.js";
+export { LiveContext } from "./contexts/live/index.js";
export {
INotificationContext,
@@ -164,6 +171,7 @@
OpenNotificationParams,
SuccessErrorNotification,
} from "./contexts/notification/types.js";
+export { NotificationContext } from "./contexts/notification/index.js";
export {
DashboardPageProps,
@@ -176,6 +184,7 @@
TextTransformers,
TitleProps,
} from "./contexts/refine/types.js";
+export { RefineContext } from "./contexts/refine/index.js";
export {
ResourceProps,
@@ -204,6 +213,7 @@
ResourceRouterParams,
RouteAction,
} from "./contexts/router/legacy/types.js";
+export { LegacyRouterContext } from "./contexts/router/legacy/index.js";
export {
Action,
@@ -216,6 +226,7 @@
RouterProvider,
RouterProvider as RouterBindings,
} from "./contexts/router/types.js";
+export { RouterContext } from "./contexts/router/index.js";
export {
ActionTypes,
@@ -224,8 +235,10 @@
} from "./contexts/undoableQueue/types.js";
export { IUnsavedWarnContext } from "./contexts/unsavedWarn/types.js";
+export { UndoableQueueContext } from "./contexts/undoableQueue/index.js";
export {
MetaContextProvider,
useMetaContext,
+ MetaContext,
} from "./contexts/metaContext/index.js";
Describe alternatives you've considered
n/a
Additional context
n/a
Describe the thing to improve
n/a
The text was updated successfully, but these errors were encountered:
Hey @pcfreak30 can you tell us which contexts do you need and which of them aren't exposed?
I need them all exposed b/c I have to track everything I may use (esp everything that Refine container builds up). The diff I gave shows that we need to export:
Is your feature request related to a problem? Please describe.
I have found some contexts are exposed and others aren't. I am requesting this be added to the exports. I found react-router does this by aliasing them with an
UNSAFE_
prefix as a practice and I think that is a good idea here.My use case is niche but I am having to do some lower level black magic with react contexts as part of a framework im creating that uses module federation, and... part of the internals requires registering/being aware of contexts in use.
I have created a patch of this locally but I think this is a small, low effort change that can be upstream'ed.
Below is a git diff of what I have done for a reference of what im requesting.
If you are open to this, LMK what you think about the naming scheme idea and which it should apply to.
Describe alternatives you've considered
n/a
Additional context
n/a
Describe the thing to improve
n/a
The text was updated successfully, but these errors were encountered: