I've created a simple app with create-react-app. This configures webpack loaders for svg files to copy the files and put a public file into the constant. So the following code
import mysvg from "./img/my.svg";
console.log(mysvg)
prints /static/media/my.svg. That's fine.
But when editing/running the same project in codesandbox it tries to read the svg file (e.g. printing errors about ReactComponent if it's not a proper svg), and makes the handling different. Obviously, I could use the "public" folder instead, but I'd like to use the hash feature of production builds etc.
So my question is, how can I allow to use the same mechanism to get a resolving url path (e.g. valid for img src) in codesandbox and use the default create-react-app configuration?
Answer from the codesandbox team: it is a known issue tracked on their github repository.
I did some digging, and I think this is definitely a bug with codesandbox.
When we use a .png image, the string path looks like this:
path: https://uploads.codesandbox.io/uploads/user/ff71cfab-643a-41c7-8358-d13e8ce686c9/U6zD-unsplash1.png
But when we use an SVG, things fail.
Some similar issues opened on their github repo: #1664, #3825.
The maintainer said that svg-react-loader is included in CRA v2 template, and you can import them as ReactComponent, I assume this is what you were talking about initially. I think this is what caused svg files to be treated differently by codesandbox.
For now, I guess you can do this hacky workaround:
import mysvg from "!raw-loader!./img/my.svg.txt";
// inside render
<span dangerouslySetInnerHTML={{ __html: mysvg }} />
sandbox here
You would need to add raw-loader as dependency and rename the file to .txt extension so that it doesn't get handled like an .svg.
Long term, I think the best we could do is to participate in #3825 and hope that this can get fixed by codesandbox.
If you're want to use svg images,only importing them as React Components, like this,import {ReactComponent as MySvg} from './img/my.svg' usually always works. There are other ways as well but I think this one is simplest.
Check out my solution -
myVersionOfCodesandbox
Related
I'm quite new to javascript and jsfiddle. I've been able to toy around with other fiddles that I find, but setting one up myself has proved difficult.
I'm attempting to use a library from npm to get a proof of concept for how it might work. I'm not sure why my import of the module is not working with jsfiddle.
What am I missing to get my fiddle working?
used the resourced bar to import the unpkg script
https://unpkg.com/browse/json-query#2.2.2/index.js
tried using the method outlined in the package readme
var json = [...]
jsonQuery('[DisplayText]', json)
When I follow the unpkg link I see that it has requires such as:
var State = require('./lib/state')
The problem is not only can the browser not understand require, it doesn't have files like ./lib/state available.
I think the problem here is that you are trying to download the raw source, which needs to be built with something like webpack before it can be used in the browser.
I'm trying to learn more about React.js from the ground up.
While reading the documentation I found that using ReactDOM.render(element, Document.getElementById("root")) would pass the JSX referenced by the word element to the element with id="root" in an HTML file. This shows what I mean.
When I looked through my repo created with the command npx create-next-app --example with-tailwindcss <app-name> I noticed that not only is there no ReactDOM.render() method being used anywhere in the file structure, but there is also no HTML file anywhere in the repo and all of the data seems to flow into index.js which returns the final JSX elements, but I can't find where that Home function is called as <Home /> anywhere.
Is there an HTML file hidden somewhere that I'm missing or is there some sort of more advanced level coding at play here that picks up the return from the Home function and does the ReactDom.render() functionality some other way? Maybe like in binary or with transpiling or something? I'd really appreciate some documentation that explains this in detail with examples.
This repo is powered by NextJs, so yes - there is an extra level on top of React, looking for any React component in pages/index.js to render the root, by naming conventions of framework, there are few places mentioning this in docs
I'm building a meteor app, and I'd like to know if it's possible to do something along the lines of:
var pages = [
'home',
'contact',
'other'
];
for(var page in pages){
import `/path/${page}`;
}
It's a small thing, but It would make things much simpler when it scales up. The above code doesn't compile, because import doesn't allow for interpolation. I've looked into using require syntax, which compiles, but can't find the files if I use interpolation. I also tried using meteor's dynamic-imports package, but couldn't figure it out.
Unfortunately most (if not all) build engines do not support interpolated import paths. They perform a static analysis to determine loaded assets.
Even Meteor dynamic imports need static paths, the "dynamic" part is about when the loading actually takes place, but Meteor still needs to know the path in advance.
Currently using Sapper to create a design system app.
I have a heirachy of folders which create the app through the routes folder.
The folder structure looks something like this:
design-foundations
- interactions
-- buttons
-- inputs
- components
-- header
Here is a look at my design-foundations/interactions/buttons.html:
<Layout>
<h1>Buttons</h1>
</Layout>
<script>
import Layout from '../../_components/helpers/Layout.html';
export default {
components: {
Layout
}
};
</script>
If you were to open up my design-foundations/interactions/inputs.html file, or any of the other files under design-foundations, you will see a file which looks very much the same, where the bottom part of the file exports the Layout component.
Is there some way I can avoid this code duplication in my files?
I would really like to somehow avoid the tag at the end of each of these files if somehow possible.
This might not be the answer you are after, but you no longer need to load the layout into your component, rather the component is now loaded in the layout. Upgrade to the latest version of Sapper and you will see the directory structure changes along with the new App.html that you need to add in your code.
Does using the JavaScript import statement for images, css and others defeat the purpose of import statement which was designed to import only the JS Modules ?
Of course, for now it gets transpiled to ES5 require using webpack. But that same question comes up again. Is it incorrect to use import statement to import images or css or files ?
EDIT:
I like the idea of controlling imports that we can control the assets on build time in such a clean way - The idea that I use the image path to import the image, and
on different environments the image path would contain different values - url or path
this image can be compressed on build time
the JS module importing this image can contain the image dimensions through a custom loader
assets dependency tree is maintained at one place and un-imported items gets chucked away automatically
rebuild time is fast - DX(developer experience) would be good
I guess, this is much better than using any templating, using placeholders in the JS files to inject URLs or paths based on environment during pre-build (webpack).
But using the import statement feels not right to do so in terms of principle or semantics.
This is from Mozilla Developer Network:
The import statement is used to import functions that have been exported from an external module, another script, etc.
From everything I've read on MDN and other sources its purpose is to make a module/script methods and properties available within the current scope it's being imported into.