In React Native:
I would like to import a file using require at runtime.
e.g.
let mydata = require('../data/' + new Date().getFullYear().toString() + '.json');
Since I have more than a couple hundred json files it is not feasible to hard code all the files.
in angular you can just use the above code and it works, but I think RN requires a static path. I am hoping there is an alternative way to do it.
any help appreciated!!!
This is one of the problems i have encountered. As i have heard of, react's require()only uses static url not variables, that means that you have to do require('/path/file'). Here is my version of solution:
const images = {
profile: {
profile: require('./profile/profile.png'),
comments: require('./profile/comments.png'),
},
image1: require('./image1.jpg'),
image2: require('./image2.jpg'),
};
export default images;
not the best option, but you can get away with it sometimes.
Related
I am working in Flutter and trying to open a json file in my assets folder. I found I can use the File() method, but it only seems to take an absolute path. Is there a way I can convert this to a relative path? I've tried using the relative path to the file already, but it returns an error saying no such file.
Here is the code so far. Basically I want to get the json file, and return it as a string (in the function readFileSync() below). Then I use that data to create a List object. If there's a better way to read a file into Flutter, I'm open to that too!
List<Answers> myFunction2() {
String arrayObjsText = readFileSync();
//print(arrayObjsText);
var tagObjsJson = jsonDecode(arrayObjsText)['tags'] as List;
var tagObjs =
tagObjsJson.map((tagJson) => Answers.fromJson(tagJson)).toList();
return tagObjs;
}
String readFileSync() {
String contents = new File(
'/Users/pstumbaugh/Documents/Computer Science/CS492 Mobile Dev/Dart-Flutter-CallMeMaybe/project3/assets/answers.json')
.readAsStringSync();
return contents;
}
I don't know much about how Futures work. I tried with those, but it seems like it always returns a Future and I'm not sure how to unpack that down to just a string without having to make everything async functions, which then led to problems when I try to get the List in my widgets on the main page...
You should to get assets not from relative path from your PC. When you install an app for a device or a emulator/simulator, it is can't access files on your computer. In few words, you can do it with loadString method from flutter/services.dart package (it is in Flutter SDK by default):
import 'package:flutter/services.dart' show rootBundle;
final data = rootBundle.loadString('assets/answers.json');
And make sure that you declared assets in pubspec.yaml config. Here is an official tutorial for how to work with assets.
I've got an Angular6 app that is being built as more of a framework for internal apps. The header / footer / major navigation will be shared, but each app (feature module) should have internal flows separate from each other. For example one feature might be purchasing, another might be onboarding, another might be a sales dashboard. They're very different from each other.
What I'm trying to do is come up with a declarative way to define known configurations for each feature. For example, the minor navigation (page to page within a feature), top level header title, and various other context related data points. My initial thought was to have them defined as JSON within each feature, which works great except I now have to import every feature's config regardless of whether a user navigates, or even has access to, that feature.
I've already got the context service set up that is checking the URL on navigation and setting some items, but again, it has to import all possible configs using this at the top of that service.
import { fooConfig } from '#foo\foo.config';
import { barConfig } from '#bar\bar.config';
import { bazConfig } from '#baz\baz.config';
So the question is: Is there a way for me to check the URL on navigation, and within that subscription, pick up the config from the correct file without pre-maturely importing them? Or maybe I can use the module to express / declare those options?
Using Typescript's Dynamic Import Expressions might be a viable option in your case..
let config;
switch (val) {
case 'foo': config = await import('#foo\foo.config'); break;
case 'bar': config = await import('#bar\bar.config'); break;
case 'baz': config = await import('#baz\baz.config'); break;
}
Though, as far as I know, there's now way at the time of writing to use variables for the import string (e.g. await import(path)).
updateConfig(feature: string) {
import(`../configs/${feature}.config.json`).then(cfg => {
this._currentConfig$.next(cfg);
});
}
The above snippet shows what I came up with. It turns out WebPack can't digest the # paths you normally use on imports and you also can't use fully variable paths. All possible options for the module package must have some common part of the path. I ended up moving my configs from #foo\foo.config.ts to #core\configs\foo.config.json. Which makes them less modular because now core is holding their config, but it makes the module lazy.
I am trying to show a diff for two JSON objects in Angular 4 view, I am using this library (angular-object-diff) originally built for AngularJS.
Demo of that library: Link
I tried to import this JS library the following way:
JS file I am trying to import: angular-object-diff.js, doesnt have a exported variable
In my typings.d.ts ( I added the following):
declare var ObjectDiff: any;
In my angular-cli.json, I added
"scripts": [
"../node_modules/angular-object-diff/dist/angular-object-diff.js"
],
In my component file:
const json1 = {
name: 'John'
};
const json2 = {
name: 'Johnny'
};
const diff = ObjectDiff.diffOwnProperties(json1, json2);
this.jsonViewData = ObjectDiff.toJsonDiffView(diff);
In my view:
<pre ng-bind-html="jsonViewData"></pre>
<pre> {{jsonViewData}}</pre>
Nothing seems to be working, I get the error that "ObjectDiff" is not defined in the console"
Can someone please let me know if I am doing in thing wrong ?
Suggestions for displaying the JSON diff are also welcomed :)
** Thank you
The library doesn't export anything. It uses IIFE to not pollute global scope with local variables. It's impossible to reach local variables from the outside, this makes Module pattern so effective (and annoying).
The library uses AngularJS angular global and expects that it will exist. This creates a problem, because Angular 4 application should mock angular global in this case. Moreover, the code itself relies on AngularJS-specific units ($sce service).
The library should be forked and modified to suit the expectations. The mentions of angular should be removed. Considering that script will be executed in module scope, IIFE should be removed and appropriate exports should be added.
I am trying to bulid a simple app using Vue / Vuex starting from vue-cli webpack template.
The app works fine but I would like to add the possibility to load and save the state in a JSON file.
Is there a best practice in order to do that ?
My first idea was to read the data into the file store.js
import Vue from 'vue'
import Vuex from 'vuex'
import fs from 'fs'
// Read file
let loaded = null
fs.readFile('./data.json', 'utf8', (err, data) => {
if (err) throw err;
loaded = data;
})
Vue.use(Vuex)
const state = {
notes: loaded,
activeNote: {}
}
...
...
But I am getting error when I try to import fs module.
There are great plugins available for exactly what you're trying to do.
Basically, having Vuex and defining a state is he way to go, however, you should do it a little different.
Take a look at this plugin:
https://github.com/robinvdvleuten/vuex-persistedstate
Since you're using Webpack it is pretty easy to install, use yarn add vuex-persistedstate for example..
Then, you import the plugin using import createPersistedState from 'vuex-persistedState'.
Now you change up your store a little bit, doing something like this:
export const store = new Vuex.Store({
state: {
yourVar: 0
},
mutations: {
changeValue (state, number) {
state.yourVar += number
}
},
plugins: [createPersistedState()]
})
That's basically it. All you need to do is add the plugin line to your Vuex store and all variable data inside your state will be saved in the browsers localStorage by default. Of course, you can read through the GitHub repository to see how you can use sessions, cookies etc, but that should work just fine.
The important part here are your mutations, since everything you want to do with your store variables HAVE to be declared by a mutation function.
If you try to modify your stored variables using ordinary functions, you'll get some warnings. The reason behind this is to ensure that no unexpected mutation of your data will take place, so you have to explicitly define what you want your program to accept in order to change your variables.
Also, using the export const store before your new Vuex.Store allows you to import that state in any of your Vue components and call the mutation functions out of there as well, using store.commit('changeValue', number).
I hope this answer helps you out a little bit, I was struggling with the exact same problem about 2 days ago and this is working like a charm ;)
I am currently learning Meteor and I found out something that intrigued me.
I can load HTML and CSS assets from a JS file using the import statement.
import '../imports/hello/myapp.html';
import '../imports/hello/myapp.css';
import * as myApp from '../imports/hello/myapp.js';
This was a surprise to me so I ran to google but could not find this behavior documented in the specification for ES6 import or in Meteor's Docs.
So my questions are:
Can I rely on this behavior to build my apps?
Will my app will break when Meteor gets around to fix it -- if it's a bug --?
Notes
I am using Meteor v1.3, not sure if this works also with previous versions.
You can download the app to see this behavior from Github
After going through the implementation of the built files for my app
I found out why this works.
HTML
Files are read from the file system and their contents added to the global Template object, e.g.,
== myapp.html ==
<body>
<h1>Welcome to Meteor!</h1>
{{> hello}}
</body>
results in the following JS code:
Template.body.addContent((function () {
var view = this;
return [
HTML.Raw("<h1>Welcome to Meteor!</h1>\n\n "),
Spacebars.include(view.lookupTemplate("hello"))
];
}));
Which is wrapped in a function with the name of the file as it's key:
"myapp.html": function (require, exports, module) {
Template.body.addContent((function () {
var view = this;
return [
HTML.Raw("<h1>Welcome to Meteor!</h1>\n\n "),
Spacebars.include(view.lookupTemplate("hello"))];
}));
Meteor.startup(Template.body.renderToDocument);
Template.__checkName("hello");
Template["hello"] = new Template("Template.hello", (
function () {
var view = this;
return [
HTML.Raw("<button>Click Me</button>\n "),
HTML.P("You've pressed the button ",
Blaze.View("lookup:counter",
function () {
return Spacebars.mustache(view.lookup("counter"));
}), " times.")
];
}));
},
So all of our HTML is now pure JS code which will be included by using require like any other module.
CSS
The files are also read from the file system and their contents are embedded also in JS functions, e.g.
== myapp.css ==
/* CSS declarations go here */
body {
background-color: lightblue;
}
Gets transformed into:
"myapp.css": ["meteor/modules", function (require, exports, module) {
module.exports = require("meteor/modules").addStyles("/* CSS declarations go here */\n\nbody {\n background-color: lightblue;\n}\n");
}]
So all of our CSS is also now a JS module that's again imported later on by using require.
Conclusion
All files are in one way or another converted to JS modules that follow similar rules for inclusion as AMD/CommonJS modules.
They will be included/bundled if another module refers to them. And since all of them are transformed to JS code
there's no magic behind the deceitful syntax:
import '../imports/hello/myapp.html';
import '../imports/hello/myapp.css';
They both are transpiled to their equivalent forms with require once the assets have been transformed to JS modules.
Whereas the approach of placing static assets in the imports directory is not mentioned in the official documentation,
this way of importing static assets works.
This seems to be at the core of how Meteor works so I'd bet this functionality is going to be there for a long while.
I don't know if to call this a feature maybe a more appropriate description is unexpected consequence but that would
only be true from the user's perspective, I assume the people who wrote the code understood this would happen and perhaps even
designed it purposely this way.
One of the features in Meteor 1.3 is lazy-loading where you place your files in the /imports folder and will not be evaluated eagerly.
Quote from Meteor Guide:
To fully use the module system and ensure that our code only runs when
we ask it to, we recommend that all of your application code should be
placed inside the imports/ directory. This means that the Meteor build
system will only bundle and include that file if it is referenced from
another file using an import.
So you can lazy load your css files by importing them from the /imports folder. I would say it's a feature.
ES6 export and import functionally are available in Meteor 1.3. You should not be importing HTML and CSS files if you are using Blaze, the current default templating enginge. The import/export functionality is there, but you may be using the wrong approach for building your views.