Skip to content

Conversation

@usmanyunusov
Copy link
Contributor

Conventions

Fix #766

@netlify
Copy link

netlify bot commented Sep 11, 2022

👷 Deploy request for effector-docs pending review.

Visit the deploys page to approve it

Name Link
🔨 Latest commit 5343de4

Copy link
Member

@igorkamyshev igorkamyshev left a comment

Choose a reason for hiding this comment

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

Thanks for a contribution 💙

export const {Provider} = ScopeContext

function getScope() {
export function getScope(forceScope?: boolean) {
Copy link
Member

Choose a reason for hiding this comment

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

In my opinion, it is better not to export this function from public module, let's move it somewhere inside the package?

Copy link
Contributor Author

@usmanyunusov usmanyunusov Sep 11, 2022

Choose a reason for hiding this comment

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

Maybe take move everything the scope.ts into an ssr.ts. Leave only public methods in the ssr.ts.

Copy link
Member

Choose a reason for hiding this comment

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

Yep, that would be better move 🤔

getScope should not be public, that's for sure

@usmanyunusov usmanyunusov force-pushed the feat-force-scope-useUnit-solidjs branch from e3e495c to 4233ac9 Compare September 11, 2022 10:46
Copy link
Member

@AlexandrHoroshih AlexandrHoroshih left a comment

Choose a reason for hiding this comment

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

Thank you for your contribution! 🧡

Everything looks good, all test in place, feature works as expected 🔥 👍

There only few small caveats:

export function useUnit(shape) {
return useUnitBase(shape, getScope())
export function useUnit(shape, opts?: {forceScope?: boolean}) {
const scope = getScope(opts?.forceScope)
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 that /scope version of bindings should have forceScope enabled by default 🤔

I suggest to change it like that:

Suggested change
const scope = getScope(opts?.forceScope)
const scope = getScope(opts?.forceScope ?? true)

Copy link
Member

Choose a reason for hiding this comment

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

Hmm, i thougth a little more and now i suggest to do it like this:

  1. Inside getScope there should be default fallback like forceScope = true

  2. For /scope exports we don't need to do anything besides getScope() call without params

  3. For main effector-solid exports we should do something like getScope(ops?.forceScope ?? false) inside

export const {Provider} = ScopeContext

function getScope() {
export function getScope(forceScope?: boolean) {
Copy link
Member

Choose a reason for hiding this comment

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

Yep, that would be better move 🤔

getScope should not be public, that's for sure

@usmanyunusov
Copy link
Contributor Author

I don't pass the scopes.test.tsx solid test . What is the right way to test?

@AlexandrHoroshih
Copy link
Member

Hmm, @Drevoed maybe you can help? 🤔

I don't quite understand, what is happening in the tests and why changes in PR would affect this

@AlexandrHoroshih
Copy link
Member

AlexandrHoroshih commented Sep 12, 2022

@usmanyunusov nevermind, i got it.

You moved hooks into ssr.ts, while they were placed at scope.ts - it has broken the build, because it builds effector-solid/scope from this file, not ssr.ts

I suggest to revert these changes (get hooks back into scope.ts) and move getScope and related Scope context into file named like scope-context.ts or something similiar

@AlexandrHoroshih
Copy link
Member

ssr.ts would not work with Solid.js, because it never had such sub-export

There is one in React bindings, but it is a leftover of past times, when there were no other usecases for fork-api, than ssr

Now it is deprecated, basically, as /scope is much better naming now

In solid.js bindings it was done this way from the start

@usmanyunusov usmanyunusov force-pushed the feat-force-scope-useUnit-solidjs branch from ca4356c to 5343de4 Compare September 12, 2022 12:05
@usmanyunusov
Copy link
Contributor Author

@AlexandrHoroshih, Fixed

Copy link
Member

@AlexandrHoroshih AlexandrHoroshih left a comment

Choose a reason for hiding this comment

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

Looks good!

@Drevoed what you think?

@Drevoed
Copy link
Contributor

Drevoed commented Sep 13, 2022

LGTM, awesome work! Thanks :) 🚀

@AlexandrHoroshih AlexandrHoroshih merged commit b0c90be into effector:master Sep 13, 2022
@usmanyunusov usmanyunusov deleted the feat-force-scope-useUnit-solidjs branch September 13, 2022 12:59
@usmanyunusov usmanyunusov restored the feat-force-scope-useUnit-solidjs branch September 13, 2022 12:59
@usmanyunusov usmanyunusov deleted the feat-force-scope-useUnit-solidjs branch September 13, 2022 13:01
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.

Isomorphic useUnit in effector-solid

4 participants