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.

Sign up for GitHub

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

Jump to bottom

Don't synchronously unmount components after -updateState #87

Closed
cfcommando opened this issue Apr 9, 2015 · 2 comments
Closed

Don't synchronously unmount components after -updateState #87

cfcommando opened this issue Apr 9, 2015 · 2 comments
Assignees
@adamjernst
Labels
bug

Comments

@cfcommando
Copy link

CKComponentActionSend can crash if called after updateState because updating state may unmount the component synchronously.

See: #86

@adamjernst says:

This is really a bug with updateState that we plan to address shortly. It shouldn't synchronously unmount; instead that should be deferred to the end of the run loop.
@ocrickard ocrickard added the bug label Apr 9, 2015
@adamjernst adamjernst self-assigned this Apr 10, 2015
adamjernst added a commit to adamjernst/componentkit that referenced this issue Apr 23, 2015
@adamjernst
Value objects for the transactional data source
359c123 
This work is aimed at creating a new data source to replace the current implementation. The goals are:

- Fix the race conditions described in facebook#15
- Enable batching state updates to the end of the run loop as described in facebook#87
- Enable asynchronous state updates in a less hacky way
- Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async)

These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst added a commit to adamjernst/componentkit that referenced this issue Apr 23, 2015
@adamjernst
Value objects for the transactional data source
db36216 
This work is aimed at creating a new data source to replace the current implementation. The goals are:

- Fix the race conditions described in facebook#15
- Enable batching state updates to the end of the run loop as described in facebook#87
- Enable asynchronous state updates in a less hacky way
- Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async)

These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
@adamjernst adamjernst mentioned this issue Apr 23, 2015
Closed
adamjernst added a commit to adamjernst/componentkit that referenced this issue Apr 23, 2015
@adamjernst
Value objects for the transactional data source
f42136c 
This work is aimed at creating a new data source to replace the current implementation. The goals are:

- Fix the race conditions described in facebook#15
- Enable batching state updates to the end of the run loop as described in facebook#87
- Enable asynchronous state updates in a less hacky way
- Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async)

These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst added a commit to adamjernst/componentkit that referenced this issue Apr 27, 2015
@adamjernst
Value objects for the transactional data source
49a8903 
This work is aimed at creating a new data source to replace the current implementation. The goals are:

- Fix the race conditions described in facebook#15
- Enable batching state updates to the end of the run loop as described in facebook#87
- Enable asynchronous state updates in a less hacky way
- Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async)

These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst added a commit to adamjernst/componentkit that referenced this issue Apr 27, 2015
@adamjernst
Value objects for the transactional data source
374ebc8 
This work is aimed at creating a new data source to replace the current implementation. The goals are:

- Fix the race conditions described in facebook#15
- Enable batching state updates to the end of the run loop as described in facebook#87
- Enable asynchronous state updates in a less hacky way
- Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async)

These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
adamjernst added a commit to adamjernst/componentkit that referenced this issue Apr 29, 2015
@adamjernst
Value objects for the transactional data source
c86f9f2 
This work is aimed at creating a new data source to replace the current implementation. The goals are:

- Fix the race conditions described in facebook#15
- Enable batching state updates to the end of the run loop as described in facebook#87
- Enable asynchronous state updates in a less hacky way
- Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async)

These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
@adamjernst adamjernst mentioned this issue Apr 29, 2015
Merged
adamjernst added a commit to adamjernst/componentkit that referenced this issue May 4, 2015
@adamjernst
Value objects for the transactional data source
b57469f 
This work is aimed at creating a new data source to replace the current implementation. The goals are:

- Fix the race conditions described in facebook#15
- Enable batching state updates to the end of the run loop as described in facebook#87
- Enable asynchronous state updates in a less hacky way
- Allow all operations on a data source to be performed synchronously or asynchronously in a safe manner (right now, insertions are always async)

These objects are merely immutable value objects or announcers, not the actual data source implementation. That will come later.
@ghost
Copy link

ghost commented Aug 4, 2015

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

@adamjernst
Copy link
Contributor

This is fixed with the transactional data source!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@adamjernst adamjernst

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@adamjernst @ocrickard @cfcommando