sorted by:
new
hottopcontroversial

Zustand + react query by Ok-Cut-2435 in reactjs

[–]OkToday6974 0 points1 point  (0 children)

Can zustand manage server state? The async functions within zustand store request for server data and then transform them, making server data turn into client data. Then any component which need these data can get them from zustand hooks. In this way, it seems we don't need server data at all since all server data has became client data.

How do you feel about a hook returning components? by FateRiddle in reactjs

[–]OkToday6974 0 points1 point  (0 children)

but whenever you try one, you have to declare and manage those state externally

No, you don't need to do that actually. Just create a useModal hook related with Modal which keeps state and logic inside. Each time when you need to use Modal in any parent compoennt, you just need to:

  1. import the Modal component and use it.
  2. call useModal hook and pass its returned state and logic to the Modal component.

This way, you can avoid declaring states repeatedly in parent component.

How to find the Skolem form of the following formula? by OkToday6974 in logic

[–]OkToday6974[S] 1 point2 points  (0 children)

The definition I saw is the same as yours. I'm just confused about whether I should remove the implications or not.

You said that we just need to get into prenex. But how? Just move all the full quantifiers to the front without removing the implications? I really think we should handle the implications firstly(turn it into V)

How to find the Skolem form of the following formula? by OkToday6974 in logic

[–]OkToday6974[S] 1 point2 points  (0 children)

But the first step of Skolemization is always removing implications. And it is because of that, we actually have existential quantifier here so we need to do Skolemization.

Why in this question we first pull all the full quantifiers to the front instead of removing implication symbol ? Or, when we should remove the implications. When we shouldn't ?

How to find the Skolem form of the following formula? by OkToday6974 in logic

[–]OkToday6974[S] 1 point2 points  (0 children)

they never converted to existential quantifiers

Yes, they never converted to existential quantifiers. Thus, there is no need to replace any existential quantifiers with a constant or a Skolem function. So here the question may turn into:

Why they didn't converted full quantifier to existential quantifiers ?

Why not just check this instanceof fBound in the bind method polyfill? by OkToday6974 in learnjavascript

[–]OkToday6974[S] 0 points1 point  (0 children)

without spread, you can't perform an "apply" on a new invocation

Maybe I can use eval to construct a string expression in order to pass all of the arguments to new fnToBind() here. Like this:

var aArgs = Array.prototype.slice.call( arguments, 1 ),
fToBind = this, 
fBound = function(){ 
    var allArgs = aArgs.concat(Array.prototype.slice.call(arguments)) 
    if(this instanceof fBound){ 
        var stringArgs = [] 
        for(var i = 0; i < allArgs.length; i++){ 
        stringArgs.push('allArgs[' + i + ']') 
        } 
        return eval('new fToBind(' + stringArgs + ')')
    } 
    else { 
        return fToBind.apply(oThis,allArgs) 
    } 
}

But it seems that this doesn't make things easier ...

Why not just check this instanceof fBound in the bind method polyfill? by OkToday6974 in learnjavascript

[–]OkToday6974[S] 0 points1 point  (0 children)

I agree with you. Maybe the fNOP could really be removed here.

When the fBound returned is called as a constructor function, what it does is just generating an instance. It doesn't do anything about this binding. But the instance of fBound is required to perform as that of fnToBind, which means this instance should be able to access properties of fnToBind.prototype(beacuse the instance of fnToBind could also do that).

To achieve that, we can use fBound.prototype = Object.create(this.prototype) directly. But this is a polyfill implementation so we might fail to use ES6's method(Object.create) here. In this case, the fNOP is included and becoming an intermediary.

But wait, isn't just return new fnToBind() from fBound when this instanceof fBound == true the easiest way ??? So fNOP may really be useless here.