Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating configure according to the MobX docs #237

Merged
merged 1 commit into from
Oct 11, 2018

Conversation

prof-xed
Copy link

According to the latest react course and the docs of mobx, configure({ enforceActions: true }) has been changed to be configure({ enforceActions: 'observed' }) it takes multi kind of values depending to the use case But our use case case is the 'observed' one.

According to the latest react course and the [docs](https://github.com/mobxjs/mobx/blob/master/CHANGELOG.md#510--440) of mobx, `configure({ enforceActions: true })` has been changed to be `configure({ enforceActions: 'observed' })` it takes multi kind of values depending to the use case But our use case case is the `'observed'` one.
@isaachinman
Copy link
Member

@Jawhar-B Why not always?

@prof-xed
Copy link
Author

@isaachinman thanks for reply and sorry being late, you are right it make more sense even for me.
But my reason for that was this comment, the last few lines are just a briefly describing what configure is actually doing.

it's not a one teacher I heard they are more than that, when ever they arrive to this point they are not even sure if MobX will work with out of it.

by putting this thing here we are enforcing the teacher and the student to have a look on what is this and why is it exactly.
this is my perspective if am I wrong I wish a feed back 😬 to correct it as expected 🙂.

@isaachinman
Copy link
Member

Hi @Jawhar-B, I don't think I understand your comment 100%.

In regards to always vs observed... Maybe I am misunderstanding, but it seems like a very small distinction from Michel. How many unobserved observables do you have?

I don't think I understand the use case of unobserved observables, but this should probably be set to always.

@prof-xed
Copy link
Author

I will Just re-describe what I mentioned before with the Comment that Michel wrote there:
he said:

  • non observed observables can be modified outside actions.
  • The reason for that is that observables that are not being observed, (cannot cause unexpected side effects, and are from that perspective safe to modify).

I am totally sure that you have your point of using always but also as I remember from the class lessons we had used true and we saw with each others the strict one but you chose that day to give us the true one, in order to not make everything that day complected I assumed, Here I would make it always if you would like?

Now according to what is in the documentation that the observed value is the recommended one, And as an addition ~> this comment is just a kind of briefly describing what each is doing.

  1. observed <=> true which we was using
  2. always <=> strict
  3. never <=> false

going back to the docs we find that they said on the observed part:

This is the recommended strictness mode in non-trivial applications

which Improving your point exactly as it is.
As a perspective for this is you are totally right, But my point is not to use it (avoiding all these tools for only setting up) or to use it with understanding what is it doing for the student.

But as I pointed out before, this addition from me only to make the teacher(s) after you with no intend maybe search (for now) a bit more and understand why is it like so (according to the closure principle I think), and introduce it's work better than before, that will make the student more aware of it and he will got his own benefit by knowing the two others.

I don't think we still have a lot of time introducing more about MobX and React in our docs here while Class16 have React class the current Sunday 💔

Plus babel@7.1.0^ has some changes around the decorators that we have in our first MobX class, in order to follow the newer upcoming decorators as they noted there out:
https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy#babel--7x

But I didn't totally understand this comment:

in MobX 6 legacy decorators will not be supported.

Any future plans or maybe surprises are we expecting?

@isaachinman
Copy link
Member

This is the recommended strictness mode in non-trivial applications.

Nice catch. I did not see this in the updated docs. If this is the case, what you've suggested here is correct.

in MobX 6 legacy decorators will not be supported.

Yes, the decorator syntax is changing a bit right now. This is not specific to MobX, but Michel is obviously aware of it and making changes in v6. If you need help changing the curriculum let me know.

@prof-xed prof-xed merged commit f7cb703 into HackYourFuture:master Oct 11, 2018
@prof-xed
Copy link
Author

Thanks a lot for help, and yes of course I will 🙂

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.

3 participants