Skip to content

Commit 5caa65c

Browse files
authored
Make createFiber use a constructor object rather than an object literal object (#9369)
* made createFiber create a constructed FiberNode object * updated comment * satisfying flow and prettier * better comments :) * fixes flow error * updates comment * converted function constructor to a ES2015 class * Revert "converted function constructor to a ES2015 class" This reverts commit c020982. * fixed some merge conflict issues * Flow.... * removed exact types to make flow pass * opted for $FlowFixMe instead * removed exact types to make flow pass * opted for $FlowFixMe instead * run prettier
1 parent b9e92c6 commit 5caa65c

File tree

1 file changed

+56
-57
lines changed

1 file changed

+56
-57
lines changed

src/renderers/shared/fiber/ReactFiber.js

Lines changed: 56 additions & 57 deletions
Original file line numberDiff line numberDiff line change
@@ -48,7 +48,6 @@ var invariant = require('fbjs/lib/invariant');
4848

4949
if (__DEV__) {
5050
var getComponentName = require('getComponentName');
51-
5251
var hasBadMapPolyfill = false;
5352
try {
5453
const nonExtensibleObject = Object.preventExtensions({});
@@ -65,12 +64,6 @@ if (__DEV__) {
6564
// A Fiber is work on a Component that needs to be done or was done. There can
6665
// be more than one per component.
6766
export type Fiber = {|
68-
// __DEV__ only
69-
_debugID?: DebugID,
70-
_debugSource?: Source | null,
71-
_debugOwner?: Fiber | ReactInstance | null, // Stack compatible
72-
_debugIsCurrentlyTiming?: boolean,
73-
7467
// These first fields are conceptually members of an Instance. This used to
7568
// be split into a separate type and intersected with the other Fiber fields,
7669
// but until Flow fixes its intersection bugs, we've merged them into a
@@ -155,79 +148,85 @@ export type Fiber = {|
155148
// Conceptual aliases
156149
// workInProgress : Fiber -> alternate The alternate used for reuse happens
157150
// to be the same as work in progress.
151+
// __DEV__ only
152+
_debugID?: DebugID,
153+
_debugSource?: Source | null,
154+
_debugOwner?: Fiber | ReactInstance | null, // Stack compatible
155+
_debugIsCurrentlyTiming?: boolean,
158156
|};
159157

160158
if (__DEV__) {
161159
var debugCounter = 1;
162160
}
163161

164-
// This is a constructor of a POJO instead of a constructor function for a few
165-
// reasons:
166-
// 1) Nobody should add any instance methods on this. Instance methods can be
167-
// more difficult to predict when they get optimized and they are almost
168-
// never inlined properly in static compilers.
169-
// 2) Nobody should rely on `instanceof Fiber` for type testing. We should
170-
// always know when it is a fiber.
171-
// 3) We can easily go from a createFiber call to calling a constructor if that
172-
// is faster. The opposite is not true.
173-
// 4) We might want to experiment with using numeric keys since they are easier
174-
// to optimize in a non-JIT environment.
175-
// 5) It should be easy to port this to a C struct and keep a C implementation
176-
// compatible.
177-
var createFiber = function(
162+
function FiberNode(
178163
tag: TypeOfWork,
179164
key: null | string,
180165
internalContextTag: TypeOfInternalContext,
181-
): Fiber {
182-
var fiber: Fiber = {
183-
// Instance
166+
) {
167+
// Instance
168+
this.tag = tag;
169+
this.key = key;
170+
this.type = null;
171+
this.stateNode = null;
184172

185-
tag: tag,
173+
// Fiber
174+
this.return = null;
175+
this.child = null;
176+
this.sibling = null;
177+
this.index = 0;
186178

187-
key: key,
179+
this.ref = null;
188180

189-
type: null,
181+
this.pendingProps = null;
182+
this.memoizedProps = null;
183+
this.updateQueue = null;
184+
this.memoizedState = null;
190185

191-
stateNode: null,
186+
this.internalContextTag = internalContextTag;
192187

193-
// Fiber
188+
// Effects
189+
this.effectTag = NoEffect;
190+
this.nextEffect = null;
194191

195-
return: null,
192+
this.firstEffect = null;
193+
this.lastEffect = null;
196194

197-
child: null,
198-
sibling: null,
199-
index: 0,
195+
this.pendingWorkPriority = NoWork;
200196

201-
ref: null,
202-
203-
pendingProps: null,
204-
memoizedProps: null,
205-
updateQueue: null,
206-
memoizedState: null,
207-
208-
internalContextTag,
209-
210-
effectTag: NoEffect,
211-
nextEffect: null,
212-
firstEffect: null,
213-
lastEffect: null,
214-
215-
pendingWorkPriority: NoWork,
216-
217-
alternate: null,
218-
};
197+
this.alternate = null;
219198

220199
if (__DEV__) {
221-
fiber._debugID = debugCounter++;
222-
fiber._debugSource = null;
223-
fiber._debugOwner = null;
224-
fiber._debugIsCurrentlyTiming = false;
200+
this._debugID = debugCounter++;
201+
this._debugSource = null;
202+
this._debugOwner = null;
203+
this._debugIsCurrentlyTiming = false;
225204
if (!hasBadMapPolyfill && typeof Object.preventExtensions === 'function') {
226-
Object.preventExtensions(fiber);
205+
Object.preventExtensions(this);
227206
}
228207
}
208+
}
229209

230-
return fiber;
210+
// This is a constructor function, rather than a POJO constructor, still
211+
// please ensure we do the following:
212+
// 1) Nobody should add any instance methods on this. Instance methods can be
213+
// more difficult to predict when they get optimized and they are almost
214+
// never inlined properly in static compilers.
215+
// 2) Nobody should rely on `instanceof Fiber` for type testing. We should
216+
// always know when it is a fiber.
217+
// 3) We might want to experiment with using numeric keys since they are easier
218+
// to optimize in a non-JIT environment.
219+
// 4) We can easily go from a constructor to a createFiber object literal if that
220+
// is faster.
221+
// 5) It should be easy to port this to a C struct and keep a C implementation
222+
// compatible.
223+
var createFiber = function(
224+
tag: TypeOfWork,
225+
key: null | string,
226+
internalContextTag: TypeOfInternalContext,
227+
): Fiber {
228+
// $FlowFixMe: the shapes are exact here but Flow doesn't like constructors
229+
return new FiberNode(tag, key, internalContextTag);
231230
};
232231

233232
function shouldConstruct(Component) {

0 commit comments

Comments
 (0)