Edit: I've added a repo to reproduce the issue:
https://github.com/bengfarrell/tf-issue-tester
I have a single page application that uses both Posenet and FaceAPI (https://github.com/justadudewhohacks/face-api.js) in 2 different views.
Separately (when in diff demo applications), those two views work perfectly, however just importing the models in those 2 different view components while in the same application, it breaks.
My first indication that something is wrong is the warning:
engine.ts:224 webgl backend was already registered. Reusing existing backend factory.
t.registerBackend # engine.ts:224
(anonymous) # backend_webgl.ts:2801
engine.ts:224 cpu backend was already registered. Reusing existing backend factory.
But the real problem is that when running FaceAPI, I get the error:
engine.ts:583 Uncaught (in promise) TypeError: t is not a function
at engine.ts:583
at engine.ts:423
at t.scopedRun (engine.ts:434)
at t.tidy (engine.ts:421)
at l (engine.ts:583)
I'm running under the assumption that the Posenet environment is not compatible with the FaceAPI environment somehow. Ideally I'd like to clean up TFJS and start fresh with each of the 2 component views.
I've looked at the docs and tried to run engine.dispose() and engine.disposeVariables() prior to running the FaceAPI implementation, but I'm not having luck.
Does anyone have any pointers on how to properly clean up between TFJS usages? I should also probably ask for strategies on ES6 imports. Perhaps there are ways to import that don't actually create the underlying factories that the warnings are referencing. If not, I can certainly get creative with other loading strategies such as dynamic imports or appending non-module based scripts on demand to the DOM.
For reference, my imports are:
import {load, getAdjacentKeyPoints} from '#tensorflow-models/posenet';
and
import {nets, loadFaceLandmarkModel, TinyFaceDetectorOptions, detectSingleFace} from 'face-api.js';
Thanks!
Related
probably I have a conceptual error regarding Module Federation. What I am trying to do is create a "shared project" (reactcore) that loads react, react-dom, MUI, etc, but not any specific UI. and the other UI's (diverse widgets) that I want to load will reuse the react and other dependencies offered by the core (use the core just as a library provider).
what I got is that if load both scripts (mpreactcore and mpwidgets, the one with the UI) it works, but react and react-core are being loaded TWICE.
[![screenshot][1]][1]
[1]: https://i.stack.imgur.com/rXEYB.png
I am wondering if I am trying to use Module Federation the wrong way. perhaps it is mandatory that the "core" should be a "shell" and all the other widgets should be injected in the shell, for example, passing a parameter when creating a single App component? my approach is due to the fact that my widgets are loosely coupled, more like a library of utilitarian widgets rather than a massive unified UI.
thanks for your recommendations.
Hi guys i try for create global variables with file .env but not works i use react native expo
i wrote process.env.API_URL but not found this variable. What i to do for works ?
I'm desesperated
I read https://www.npmjs.com/package/react-native-dotenv and https://docs.expo.io/guides/environment-variables/ but not works for me.
I need HELP !!!
https://docs.expo.io/guides/environment-variables/#the-app-manifest-env
If you have installed the expo-constants module in your managed
workflow project, you can access the app manifest's properties. One of
these properties is the .env property, a property that is only
available when running expo start. As the name suggests, it contains
some of your system-defined environment variables. For security
reasons, only the variables that starts with REACT_NATIVE_ or EXPO_
are available.
If you want the API url to be available it needs to be prefixed with REACT_NATIVE_ or EXPO_
Defined
REACT_NATIVE_API_URL=....
or
EXPO_API_URL=....
Accessed via
process.env.REACT_NATIVE_API_URL
or
process.env.EXPO_API_URL
Edit
If using the react-native-dotenv module
Usage
Add your env key-value pairs to your .env file
API_URL=....
Now import it in your .js file
import { API_URL } from 'react-native-dotenv';
I ran into so many issues getting environment variables to work. Oddly, the most highly recommended package was react-native-dotenv, and the first line of code in index.js is to require('fs'), which is a Node module that isn't available in React Native.
Anyways, I ended up creating a new context to handle Environment Variables. I don't have logic to automatically import variables based on environment, but that's as simple as commenting out one line.
Create a JSON file with your variables, import it into your context, and place it at the top of your app.js return, allowing everything in your app to consume it. From there, import it with useContext() as you would any other context, and you have access to all your variables.
Edit: After repeated issues, I decided to simply only use production variables for app testing. It's not ideal at all, but I'm sure many are in the same position as I'm in where the only real difference in variables is the route name for the API (local test server vs. production server). Unfortunately, both iOS and Android do not support http requests, or https requests with self-signed certificates without editing config files. Those config files are not available if you're using an Expo managed flow. Thus, my only choice was to simply do my testing on the production API. Luckily, I have good logs to go by, and the API itself is fairly mature and has endured plenty of testing via the web React app.
If anyone has a better solution, I'd love to hear it.
Are there any examples out there of injecting new ReactJS components at Runtime, e.g:
A build is deployed on production is stable and running.
We need to add a component or a new route without running through an entire deploy process.
An additional usecase : the application ships with all the components ( e.g: A CMS Module library) - Only certain components were enabled in layout at build time but need more to be added later via a config.
Approaches I have considered.
Using next getStaticPaths and then using a override in the front-end to inject client side components. This will most probably be seen at runtim
Use a more faster deploy system - This is more obvious but imagine lots of changes within a day and multiple deploys.
Any similar problems or approaches people would have tried would be great.
Update Nov 2022
If you are searching on the internet and this comes up, Zack Jackson's Module Federation supposedly achieves this and is called live code sharing via Module federation - https://module-federation.github.io/ There is a NextJS Paid plugin https://app.privjs.com/buy/packageDetail?pkg=#module-federation/nextjs-mf (supports only CSR currently)
I think you would lose out on a lot of built-in build optimizations from Next by trying to circumvent the standard build process, e.g. automatic code-splitting as described here.
However, you might find the fallback feature solves your problem entirely - the fallback feature was meant for large ecommerce sites like it sounds like you're working with. As stated at the fallback true docs:
useful if your app has a very large number of static pages that depend on data (think: a very large e-commerce site). You want to pre-render all product pages, but then your builds would take forever.
So the question is if it is possible to split a React app into two different separate apps hosted on two different hosts, where the app A is a kind of a frame which controls the app B and C in the future. I have a problem, where I would like to make a common fundament for both apps (the A app) and then load two other as a content of it. It would be as if I had lazy loading with a bundle fetched from a different place. I was thinking about three main possibilities:
Iframe
Single SPA project from github
using ReactDOM.render method
I am not sure if it is possible at all, beacuse there still may be a problem with React Router - does the inside app have access to manipulate the browser routing?
It is quite possible to split your react Application into multiple smaller react applications.
Suppose you have a react application such as an e-commerce platform . You can choose to write the cart Page using a separate react-App and the products page using another separate react app and integrate them together using Module Federation Plugin webpack/lib/container/ModuleFederationPlugin.
A good reason to do something like that would be to develop different parts of your application in isolation ..and they can be taken care by different teams altogether.
There is a udemy course that teaches you exactly that. Very much recommended. You can make react dependency as singleton to avoid several installs of react.
All 3 of these options you've stated are valid and can be used to share components but there are few disadvantages to each one, for example- iFrames makes it hard to create responsiveness, ReactDOM splits your app so that the different parts won't have the same global scope...
Module-Federation is the best and most efficient way to share remote components that i know of, here is a github link to a basic project.
The MF plugin makes use of webpack's abilities, which means that the shared components are being consumed as runtime objects of the app's scope, rather then as a promise of an iframe.
NOTE: Debugging and updating a Module Federation project is a much deeper task then debugging a create-react-app application, you'll need to share dependencies correctly and remember to update desired changes at all the right places all the time.
This is not possible. Each react app can only have a single package.json in the hierarchy. if you nest it, the app will fail and say you have several installs of react. what you should do is think more react minded and objecty. You can have a folder for common components to share inside src/. You can also have src/A which is one "app". src/B which is another.
What you described in your question is exactly what you should do, just dont think of it as a react app separation, rather a seperation of component and app inside the src folder. App A can be comprised of components from /components as well as App B.
The interactive console accessible at localhost:8080/_ah/admin is very useful for debugging your App Engine app.
I always find myself importing the same modules over and over again, particularly models.
I've looked into monkey patching the interactive console to automatically import these models, and I'm stumped. Ideally, I could do it from my app so I wouldn't need to reapply the patch every time I update the SDK.
I'll investigate and hopefully find an answer, please let me know if you have any ideas about how to accomplish this.
Good question! The relevant code for the interactive console is in InteractiveExecuteHandler at google/appengine/ext/admin/init.py:188. Specifically, it executes the code like this:
try:
compiled_code = compile(code, '<string>', 'exec')
exec(compiled_code, globals())
except Exception, e:
traceback.print_exc(file=results_io)
Note that for the globals, it simply uses the globals of the module it's in. So in order to provide your own imports, all you need to do is this:
Create your own module, where you import and subclass InteractivePageHandler and InteractiveExecuteHandler
Import any additional modules and classes you want in your new module - they'll automatically be imported for any code that's executed by them.
Override the generate() function from BaseRequestHandler in those classes so they look for the templates on google/appengine/ext/admin/templates instead of in the 'templates' subdir under your own module.
I ended up using the App Engine Console project which comes with an autoexec.py that provides the functionality I asked about.
I'm not sure if this is at all what you're going for, but you can just edit the html template for the interactive console page to have different default text entered. It's located at:
./google_appengine/google/appengine/ext/admin/templates/interactive.html
This would apply to all your apps, and as you mentioned you'd have to goof with it every time the SDK updated.