Message from JavaScript discussions
February 2018
— If state.tuple.otherObj matches the structure of state.tuple.search, then you can safely assume state.tuple.otherObj[state.accessor] exists. If not, it drops objects from the tuple since it can’t figure out how to sync them up for that particular part of the graph structure
So with that in mind, the userspace code could also do dependency injection this way, including whitelist and blacklist, using custom properties
— It's just all so much more code for just 1 more parameter though
— The problem with feature detection is that you can't know if the root properties like whitelist are part of the search index or not...
— So it would be a required root property, no assumptions allowed
— And yeah I totally stress out over these interfaces lol
— Very optimistic coding style🤤
— Using shared state is usually really bad unless you do it correctly
— You might say setting some value of an object on the fly and expecting different behavior is technically a side effect
— What's wrong with just doing this?
bfs(obj, null, blacklist)
— With the null replacing whitelist for when you only want to use blacklist
— TRGWII ^ ?
I feel like having to put null to only use the blacklist is the most easy of all these ideas