This is an unusual one.
I commited a git branch, merged it, then hit undo on the merge. If I roll back to the commit (that had just been working) I get the error:
Uncaught TypeError: Cannot read properties of undefined (reading 'includes')
at UniqueComponentName (UniqueComponentName.js:13:1)
Line 13 is the opening declaration of the functional component:
export const UniqueComponentName = ({ side, mode, menuJSON, pcbData, ...props }) => {
I thought, initially, it was a problem with an 'includes' in the component but trial and error led me to discover the following:
A brand new component named UniqueComponentName, made with a
template that works under any other name, still throws this error.
If I don't include the UniqueComponentName component in any other
component, the app performs fine.
As soon as I include it, the error above is thrown. Again, the
contents of UniqueComponentName are irrelevant as I can literally
copy and paste another working component and the error comes up.
I'm wondering if it's possible that the merge and undo merge corrupted some reference to UniqueComponentName? It's a long shot, I'm aware, but I'm there has been a lot of work since the last commit.
Further info:
If of relevance:
Reactjs is running off the standard create-react-app server locally.
I have been staging commits locally, and using a 3rd party build
pipeline to run builds on anything I push to github. The builds are hosted an a remote server that isn't involved here. As far as I
know, there's no production builds locally : I just hit save on any
file as I'm working on it and see webpack compiles, browser updates,
etc.
I'm considering starting up a fresh create-react-app project and bringing in all the /src files from the current project, to see if mt theory holds up.
The error is caused by create-react-app serving old bundle files.
Those files are located in the node_modules/.cache/ folder.
Solution;
Delete the node_modules/.cache/ folder
Restart your dev-server
React should now re-create all the bundle files, sourcemaps, etc..
- Old git issue with some in-depth details
Related
Any time I import Amplify into my React Native project's App.js file, I get the following error:
TypeError: null is not an object (evaluating 'keys.filter')
Here is how I'm importing it:
I run the project using Expo only. If I comment the import Amplify line out, any other files which use anything related to Amplify cause the same error to occur.
Initially, when I was loading this project for the first time, I had other errors to deal with like first needing to create the aws-exports.js file. I copied this over from an old project (Because this is meant to be a re-do of another project that's already set up). Once I included that file I had to update a few lines in that file because of an improper reference to Linking from expo. Once I fixed that, it throw this error I'm referencing here. Now, even if I delete the aws-exports file it will throw this error as soon as Amplify is imported into the App.js file.
-- Update
I've found where the error is occurring. Some of my code gets executed but the error happens inside of the reactnative.js file when syncing between two memory software.
I've tried to reproduce this error inside a fresh react application by copying the package.js file and then importing Amplify into the App.js file but it doesn't throw this error.
Here is a screenshot of where the error is taking place. I'm still trying to figure out how to pinpoint where in my code this error begins.
According to Expo, you have to follow these steps
it would be best if you imported Amplify
import Amplify from '#aws-amplify/core'
All you need to follow those steps it sees the configuration issue result data is not coming that's why it gives a null value and crashes.
Follow steps below will fix your problem
https://blog.expo.dev/how-to-build-cloud-powered-mobile-apps-with-expo-aws-amplify-2fddc898f9a2
The problem seems to be resolved by changing the slug attribute in the react app.json file. I changed the slug from being a camel case to an all lower case slug.
After this the error has gone away for what seems permanent. I've been able to replicate the error in small sample apps. I don't understand why this causes these errors.
Initially posted this on reddit but got no response.
I last used service workers a couple years ago using CRA 3
The way I understood it was, just call the register function in the index.js file and voila, it's more-or-less working.
Pass in an config object to the call to add customizability. For me, all I needed it was for calling a callback that set redux state that was being listened to on a component that notified users if a new version was available via a snackbar. It was super easy and worked well.
Now I'm trying to implement similar functionality in CRA 4 and there's a whole layer of Google's workbox api on top of it; I'm sure it's super useful and necessary for some, but for my case -- just a call back after serviceworker registration -- it's a PITA.
First my service-worker.js file wasnt being built into the public directory so was resulting in 404s.
Only way out apparently was to create a new CRA app using cra-template-pwa then copy over the relevant files, which I've done.
Now the precaching workbox plugin is complaining about not being able to find my index html file as well as other static assets (have a multi-frontend app structure where those assets are in /app/frontendapp1(2,3,...n)/)
I've tried messing with the copied over service-worker.js file in src but my changes aren't being reflected in the public/service-worker.js file ...
Every reading I'm finding is getting really into the usages of each plugin, without an overall picture of react app via CRA -> serviceworker -> workbox. Anyone able to articulate ? Also have a couple of questions:
1- how does the public/service-worker.js file get built? Auto?
2 - is there a way to configure the public url for the precaching workbox?
I use exq and exq_ui for background job processing and monitoring in my Phoenix application.
At first, I refer to exq_ui in mix.exs's deps like this:
{:exq_ui, "~> 0.11.0", only: [:dev, :qa, :stg, :prod]}
And it works fine.
But then I discover 2 bugs in the UI:
When I click on the tab Busy, it blows up on the server side, and shows nothing in the tab Busy in UI.
In the tab Scheduled, when a job is passed args as a list of map, it is showed as [Object object] in the column Args, instead of the real content of the args.
I fix those bugs here in this PR to the main official repo:
https://github.com/akira/exq_ui/pull/89/files
But I cannot expect it will be merged anytime soon, so I change my dependency in mix.exs like this:
{:exq_ui, "~> 0.11.0",
git: "https://github.com/chauhonglinh/exq_ui.git",
branch: "feature/fix_busy_tab_in_exq_ui",
only: [:dev, :qa, :stg, :prod]}
Now the trouble happens.
The mix deps.get, mix deps.compile and iex -S mix phx.server all run successfully.
But then when I browse to http://localhost:4040, the UI doesn't show up, and in the javascript console, there are errors:
Resource interpreted as Stylesheet but transferred with MIME type text/html: "http://localhost:4040/assets/vendor.css".
exq_ui:20
Resource interpreted as Stylesheet but transferred with MIME type text/html: "http://localhost:4040/assets/exqui.css".
vendor.js:1 Uncaught SyntaxError: Unexpected token <
exqui.js:1 Uncaught SyntaxError: Unexpected token <
Question: Why did this error not happen with ordinary deps config, but it happened with deps config referred to a git repo?
How can I fix it?
I think React and Angular also have similar errors in certain situations, but it seems that nobody has a good fix for them, just some anecdotes here and there.
I figured out what the problem was. But I don't see any good solution for it yet if my PR is not merged (short of copying the whole exq_ui package and create a new one)
Here is the problem.
Referring to package like this points to binary distribution on hex.pm, hence it has all the emberjs and js modules prepackaged and babelified correctly:
{:exq_ui, "~> 0.11.0", only: [:dev, :qa, :stg, :prod]}
However, the referring to package in github points to source from github, so it has only source:
{:exq_ui, "~> 0.11.0",
git: "https://github.com/chauhonglinh/exq_ui.git",
branch: "feature/fix_busy_tab_in_exq_ui",
only: [:dev, :qa, :stg, :prod]}
Solution for dev environment:
In order for it to work in dev environment, from within my Phoenix repo, I need to run the following commands:
cd deps/exq_ui/priv/ember
npm install
bower install
node_modules/ember-cli/bin/ember build --environment=production
Then the web UI at http://localhost:4040 will work properly.
Remaining Question: When I refer to exq_ui from a git repo, I still don't see how I can make a binary distributed version for exq_ui when I want to release my Phoenix app.
I have a React app created using Create React App that was running fine until today. Something must have updated the last time I installed a new package. Anyhow, so whenever I try to start the app, it complains that there are .ts files (within node_modules folder) and forces me to install TypeScript.
Is there any way to stop this behaviour? Because currently, installing TypeScript just opens a bottle of worms, where I need to resolve the TypeScript errors that arises.
Also, as the screenshot suggests, removing the tsconfig.json file doesn't resolve the issue, it gets automatically created on every run..
Currently because it's preventing me to work, I've done the following modification until they fix it on the Create React App:
Current solution until they fix the create react app
On the file node_modules/react-scripts/scripts/utils/verifyTypeScriptSetup.js, find the definition of verifyNoTypeScript() (line 24). Replace the function to the following:
function verifyNoTypeScript() {
return true;
}
In a recent SDK update, it seems that Google has added a INFO level log into the dev_appserver that prints out each and every time a file change is detected.
This, in my opinion, just clutters up the log with information I already know thus I don't want it to be printed out on my console.
INFO 2014-11-27 09:52:43,876 module.py:391] [default] Detected file changes:
/Users/michael/app/templates/home
/Users/michael/app/templates/home/index.html
Is there any way to remove these lines from the log? Since this is a INFO level log, I can't really remove the INFO from the log_level as other INFO logs come in handy many times...
Any suggestions?
It's now an issue on the App Engine issue tracker. Vote it up for quicker resolution.
https://code.google.com/p/googleappengine/issues/detail?id=11662
This issue started to bug me also, so here's my quick-fix until devs find more permanent solution:
in path-to-SDK\google\appengine\tools\devappserver2\module.py comment out lines 424-426.
424 # logging.info(
425 # '[%s] Detected file changes:\n %s', self.name,
426 # '\n '.join(sorted(file_changes)))
Just have to remember to do it again when the build changes, if they don't fix it. (I'm working with 1.9.20 atm) (:
As Derek Perkins pointed out, this was sent to the App Engine Issue tracker. Since I had the same problem I starred the issue. I was happily surprised to see it was actually sent up to engineering and they updated the tracker today with a workaround. I rewrote parts of it and added a bit of formatting :)
Root cause of the problem
The main reason behind why every file in a project's folder is tracked is because the reload logic is naïve and has no way of knowing which files are actually being in use.
In the event that some data file contents are changed, but only loaded at module import time (for instance templates in some frameworks), it's difficult for the devserver to accurately detect such changes.
Workaround for Git and Mercurial
If you put your project folder anywhere but the root of your git repo, it will make all the .git files appear outside of your project's dir, so the changes to the files should not be seen and therefore shouldn't trigger a webserver reload. For instance build your project's structure this way :
myproject/
myproject/.git/
myproject/.gitignore
myproject/myapp/
myproject/myapp/app.yaml
myproject/README
Then run the devserver inside of myproject/myapp instead of "myproject".
There is also a mention that this has been tested on Git and Mercurial, but it won't work on CVS or SVN.