Summary:
The existing loading page was not behaving the way it was intended. The previous implementation triggered a page reload which made the whole retry mechanism useless.
Instead, a new endpoint was defined to expose whether the server is ready or not. Use this instead as a way of knowing whether we are good to reload the page.
Reviewed By: passy
Differential Revision: D49314749
fbshipit-source-id: eb67765d7deab8610fa5d31e710070da43a18c1c
Summary:
This is an automated PR to update the Podfile.lock.
- Make sure that the Podfile.lock contains latest FlipperKit and Flipper pod versions.
- Also make sure that all the dependencies are updated to the latest one.
- This is auto-generated by [create-pull-request](https://github.com/peter-evans/create-pull-request)
Pull Request resolved: https://github.com/facebook/flipper/pull/5147
Reviewed By: lawrencelomax
Differential Revision: D49313900
Pulled By: passy
fbshipit-source-id: 95ca11cb6354502097fb7b831fbafc6011fd4a97
Summary: Bloks ios is serializing some ns dictionary without registering the metadata, this means the look up fails. That said regsitering metadata for dictionarys where the keyspace is unbounded doesnt make any sense so for this case we can just fall back to the key as the name. Since we can rely on the id lookup passing we iterarates the enties of the object
Reviewed By: passy, ivanmisuno
Differential Revision: D49314398
fbshipit-source-id: 65f7beb0d8402b08a68b9f00b7605e0b6c44766f
Summary:
There was a frustrating issue previously where the UI would jump everytime a new frame came in with bloks data. This would occur constantly as the client was generating new frames every 10 seconds. The issue was because the previous appraoch to speed up the augmentation was to display the raw client raw and then asynchronously process a new frame with the added derived components.
The issue was the raw client frame has less nodes so we would breifly display this, and because the reduciton trace was cache on the next tick we would show this causing a jump.
Now we have a new solution:
1. We use an event emitter to push frames / metadata into the interceptor
2. The interceptor should always produce 1 frame, this can be the same or augmented, for open source its just the same
3. We use react query to check if we already have the reduction trace cached, if so then we are able to quickly process the whole thing, if not its split into 2 parts.
React query is also nice since we can add a cache time for the reduciton traces which are very large and not useful one your screen is gone. This should help keep memory usage under control a bit.
one other benefit to this approach is i can remove the error handling stuff from the main plugin code, since the blok augmentation is not on the critical path and it can retry internally and push out a new frame whenever.
Reviewed By: antonk52
Differential Revision: D49272152
fbshipit-source-id: e5539d36231a32754e8612014195449b9faafdb1
Summary:
We had our stack traces broken for a long time. They always pointed at the bundle.js file. With this change the stack traces **in the console** will be pointing at the actual source files. This will save a lot of time for engineers instead of manually looking for the source of errors.
Why this didn't work before?
When we were calling `console.error(error.toString())` the browser was not applying sourcemaps to the stacktrace as it interpreted as a random string. However, when you pass an actual instance of Error constructor, the sourcemaps will be applied and we get correct stack traces to the source files.
I looked at the code of the Logger and it is already handles the Error instances, so I think this should be fine also for the logs that go to scuba. CC passy
Reviewed By: LukeDefeo, passy
Differential Revision: D49275025
fbshipit-source-id: 2addc601f45622e35890d7d0e1992f4bca41a338
Summary: Generate auth token on whenever we load the secure server config, and add more logs.
Reviewed By: antonk52
Differential Revision: D49272857
fbshipit-source-id: 1e549a8bfd7926e9a44b9480432e92ee3c0162b2
Summary:
A few things need to be done which are on this change:
- Certificate generation should execute as an atomic operation, hence, it needs to be synchronised.
- Do not generate client token as part of certificate generation. This causes a deadlock now.
- Add more logs for troubleshooting
Reviewed By: aigoncharov
Differential Revision: D49269624
fbshipit-source-id: 071a8e5b895198730b7d914cc4622837e9094e2f
Summary: The `visible` prop is marked as deprecated in favour of `open`
Reviewed By: passy
Differential Revision: D49226821
fbshipit-source-id: 4a4a7d03a1c8ff860c4e4cd02e19071185a8554e
Summary: Shows up in the console as a warning. Easy to fix.
Reviewed By: lblasa
Differential Revision: D49189263
fbshipit-source-id: 40428434803db708789811352b76004549d8c086
