Bug on integrating Material UI hooks and Apollo hooks - material-ui

When using Material UI hooks (as its example shown here) with NextJS and react-apollo-hooks, received bug -
TypeError: Cannot read property 'theme' of undefined
at MyDocument.render (/material-ui/examples/nextjs-hooks-with-typescript/.next/server/static/development/pages/_document.js:156:38)
Expected Behavior 🤔
Able to use Material UI hooks and Apollo hooks together.
Current Behavior 😯
undefined pageContext caused TypeError: Cannot read property 'theme' of undefined at line:
https://github.com/ivawzh/material-ui/blob/fc6ae01e66bde4252a08903719a59ef108e05e5f/examples/nextjs-hooks-with-typescript/pages/_document.tsx#L14
Steps to Reproduce 🕹
This codesandbox.io template _may_ be a good starting point:
https://codesandbox.io/s/github/mui-org/material-ui/tree/master/examples/create-react-app
If you're using typescript a better starting point would be
https://codesandbox.io/s/github/mui-org/material-ui/tree/master/examples/create-react-app-with-typescript
If YOU DO NOT take time to provide a codesandbox.io reproduction, should the COMMUNITY take time to help you?
-->
I have prepared a repo here https://github.com/ivawzh/material-ui/commit/fc6ae01e66bde4252a08903719a59ef108e05e5f
Steps:
git clone git#github.com:ivawzh/material-ui.git
cd material-ui/examples/nextjs-hooks-with-typescript
npm install && npm run dev
In web browser, open http://localhost:3000/countries2
See the error in your terminal
Context 🔦
I am trying to use Apollo hooks with Material UI hooks example.
From the repo above you will see the non-hook Apollo endpoint at http://localhost:3000/countries is working fine as expected. But when Apollo hooks is in used, app will crash because pageContext becomes undefined.
Environment 🌎
https://github.com/ivawzh/material-ui/tree/fc6ae01e66bde4252a08903719a59ef108e05e5f/examples/nextjs-hooks-with-typescript
| Tech | Version |
|--------------|---------|
| Material-UI | v3.8.1 |
| React | 16.7.0-alpha.2 |
| Browser | Chrome |
| TypeScript | 3.2.2 |
| react-apollo | 2.3.3 |
| react-apollo-hooks | 0.2.1 |
Related Git issues
https://github.com/mui-org/material-ui/issues/14140

Related

Airflow duplicated plugin entries in virtualenv

Was setting up Airflow (2.1.4) in a virtual environment followed by an install of a third-party plugin "pip install simple-dag-editor"
Plugin installed successfully, however upon checking the plugin list, there were duplicated entries.
(venv) root#test-server:/opt/airflow$ airflow plugins
name | source | flask_blueprints | appbuilder_views
==================+============================================================+=======================================================+=============================================================
simple_dag_editor | simple-dag-editor==0.1.1: | <flask.blueprints.Blueprint object at 0x7f69e5e427b8> | {'category': 'Admin', 'name': 'Simple DAG editor', 'view':
| EntryPoint(name='simple_dag_editor', value='simple_dag_edi | | <simple_dag_editor.app_builder_view.AppBuilderDagEditorView
| tor.simple_dag_editor:SimpleDagEditor', | | object at 0x7f69e5dd1470>}
| group='airflow.plugins') | |
simple_dag_editor | simple-dag-editor==0.1.1: | <flask.blueprints.Blueprint object at 0x7f69e5e427b8> | {'category': 'Admin', 'name': 'Simple DAG editor', 'view':
| EntryPoint(name='simple_dag_editor', value='simple_dag_edi | | <simple_dag_editor.app_builder_view.AppBuilderDagEditorView
| tor.simple_dag_editor:SimpleDagEditor', | | object at 0x7f69e5dd1470>}
| group='airflow.plugins') | |
Airflow portal also resulted in 2 entries in the "Admin" section
Any idea what is happening? I tested the setup again both on a docker container and standalone on the server. Both instances did not result in the duplicated entries therefore I am suspecting it is related to running Airflow in a Python virtual environment. The server is running on CentOS 7.
I believe you might have plugin installed twice in two different places:
In "plugins" folder as simply a python package
Installed as python package
Aiflow Allows for both types of installations, and I think if you have both - it will install both.
If you change the airflow log level to verbose, you should be able to see two entries:
"Loading plugins from entrypoints"
"Loading plugins from directory: <DIRECTORY>"
They should be followed by attempts to import the plugins.
The solution would be to remove the plugings from the "plugins" directory.
It's also possible that you have two packages that have the same entrypoint - for example if you installed it with different package name before, it could also be discovered twice. Airflow checks all pacakges available and if they have appropriate entrypoint declared, it will load it as plugin. But if you enable DEBUG logging level, you should see details. You can easily set airflow logging level by config option (or environment variable):
https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#logging-level

How can I make setup.py to include a class into packaging

I'm using setup.py to package my project. the structure is like:
foo -
|
|--foo/
| |
| |--first.py
| |--second.py
| |--...
|--README
|--requirements.txt
|--scripts/
| |
| |-script1.sh
| |-script2.py
|--service.py
|--setup.py
If I run the current setup.py, which is in accordance with the suggestions here: What is setup.py?
then in the venv/lib/python3.6/site-packages/foo and venv/lib/python3.6/site-packages/scripts I can see all python classes there. But service.py is absent. My question is how to modify the setup.py to include service.py into packaging such that I can find service.py at venv/lib/python3.6/site-packages/?
Thanks in advance!
For top level modules, such as service.py, to be included in the distributions, setuptools offers the py_modules parameter.
The setuptools documentation does not show it clearly, but it is the same as in (now deprecated) distutils:
https://docs.python.org/3/distutils/setupscript.html#listing-individual-modules
setuptools.setup(
# ...
py_modules=['service'], # no '.py'
)

VS Code Extension Settings CLI

I want to create an automated script for setting up VS Code.
Part of this is the installation of the extensions and configuring them as necessary.
So I was able to install the extensions via CLI, but can't find how to change the extension settings by only using the command line.
For example - I want to change Jest Runner settings. I found this on their readme:
Jest Runner will work out of the box, with a valid Jest config.
If you have a custom setup use the following options to configure Jest Runner:
| Command | Description |
| --- | --- |
| jestrunner.configPath | Jest config path (relative to ${workFolder} e.g. jest-config.json) |
| jestrunner.jestPath | Absolute path to jest bin file (e.g. /usr/lib/node_modules/jest/bin/jest.js) |
| jestrunner.debugOptions | Add or overwrite vscode debug configurations (only in debug mode) (e.g. `"jestrunner.debugOptions": { "args": ["--no-cache"] }`) |
| jestrunner.runOptions | Add CLI Options to the Jest Command (e.g. `"jestrunner.runOptions": ["--coverage", "--colors"]`) https://jestjs.io/docs/en/cli |
| jestrunner.jestCommand | Define an alternative Jest command (e.g. for Create React App and similar abstractions) |
| jestrunner.disableCodeLens | Disable CodeLens feature
| jestrunner.codeLensSelector | CodeLens will be shown on files matching this pattern (default **/*.{test,spec}.{js,jsx,ts,tsx})
But don't know how to access it via cmd.
Any thoughts on how to do this?
Thanks!
Was able to find a solution now.
So it turns out that the settings are actually stored in:
<userFolder>\AppData\Roaming\Code\User\Settings.json
From there I can open up the json file and add in the commands as specified by the extension's readme.

VS Code not excluding Code's node_modules from being watched - file watch limit reached

In VS Code, I have a Vue project with less than 50 files but upon running the dev server VS Code throws Error: ENOSPC: System limit for number of file watchers reached.
My VS Code Watcher Exclude settings have the following ignore patterns.
**/.git/objects/**
**/.git/subtree-cache/**
**/node_modules/**
I tried to figure out what files could possibly be setting me over the max_user_watches limit on my machine, which is 8192.
With a StackExchange answer from user "mosvy" and a script derived from that answer by another user "oligofren", I've found that the following sources are likely causing this.
| Watchers | Source |
| -------- | ------ |
| 4033 | /usr/share/code/code --max-old-space-size=3072 /usr/share/code/resources/app/extensions/node_modules/typescript/lib/tsse |
| 3889 | /usr/share/code/code /usr/share/code/resources/app/extensions/node_modules/typescript/lib/typingsInstaller.js --globalTy |
| 99 | /usr/share/code/code /usr/share/code/resources/app/out/bootstrap-fork --type=watcherService |
I'm not sure why any of these are being watched, but the first two seem to be ignoring VS Code's Watcher Exclude setting of **/node_modules/**
If possible, is it safe to exclude all three of these in the Watcher Exclude settings of VS Code?
I don't want to break my VS Code install.
Update
The Watcher Exclude settings above are what VS Code has listed as default. I added the same settings
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/node_modules/**": true
}
directly to the settings.json file and the two node_modules sources listed above were removed and the error went away for that session.
After restarting VS Code and verifying that settings.json still included the changes I made, the two node_modules sources from before are no longer being excluded.
I had the same issue.
I did not found a solution, but a workaround.
Just disable this built-in extension: TypeScript and JavaScript Language Features

Could not find openssl in backend

Error I get:
error[E0433]: failed to resolve: could not find `openssl` in `backend`
--> ...\src\...\swagger-0.12.1\src\connector.rs:41:34
|
41 | native_tls::backend::openssl::TlsConnectorBuilderExt::from_openssl(ssl);
| ^^^^^^^ could not find `openssl` in `backend`
error[E0433]: failed to resolve: could not find `openssl` in `backend`
--> ...\swagger-0.12.1\src\connector.rs:85:34
|
85 | native_tls::backend::openssl::TlsConnectorBuilderExt::from_openssl(ssl);
| ^^^^^^^ could not find `openssl` in `backend`
Compiling hyper v0.2.1
error: expected identifier, found `"rustc-serialize"`
--> ...\hyper-0.2.1\src\lib.rs:129:14
|
129 | extern crate "rustc-serialize" as serialize;
| ^^^^^^^^^^^^^^^^^ expected identifier
Generated a server stub user swagger. Ran into issues where cargo couldn't find openssl, giving an error like 'custom build something openssl-sys 0.9.24'. This was a known issue and I overcame it by downloading vcpkg, and using vcpkg to download openssl. Then using environment variables to point to the download folder so cargo could use openssl. But now the error seems to be that openssl doesn't exist in backend?
It also seems to specific to windows, any ideas?
Tried changing the version of native-tls to the most up to date version but it doesn't seem to have an affect at all. It looks like swagger's dependencies need updating but I literally just generated this stub...
You've landed on a flaw from the Rust documentation tools; it picks up what is in a package, but doesn't show the limits.
The backend module definition is defined as:
#[cfg(any(target_os = "macos", target_os = "ios"))]
pub mod security_framework;
#[cfg(target_os = "windows")]
pub mod schannel;
#[cfg(not(any(target_os = "macos", target_os = "windows", target_os = "ios")))]
pub mod openssl;
In other words, the situation is the following:
If you are on linux (i.e. not macOS, not windows, not iOS), then openssl is available
If you are on windows, then schannel is available
If you are on MacOS or iOS security_framework is available
You should, however, not be trying to target a specific backend, as this defeats the purpose of the library. Instead of importing native_tls::backend::openssl::TlsConnectorBuilderExt, import native_tls::TlsConnectorBuilder and let it decide what backend you need.
This may be easier said than done, however, since by the looks of your error this is caused by a third-party library, which indicates that it was only tested on Linux.