I've got this sort of general question when it comes to requiring images in React Native. I've got this application that uses the same little red x and green check mark for form validation 6-8 times in a single form component. How it stands right now, I have a require in every 'source' prop when used.
Is it best practice to require the image once at the top of the component as a variable and just use the variable 6-8 times instead of the calling require for each one of them?
Yes, requiring it once at the top is far superior.
But hey, you can go even further. If this is an icon you need to use across the app, it might be worth making a very very simplistic component that renders this image. It's easier to reference <GreenCheck/> than to require an image and stick it into an img tag repeatedly.
Related
I would like to render DOM elements (which im otherwise using React for) onto (for example) a plane in a 3D (WebGL -> Three.js -> Three Fiber (??? so far best way to go about it as im figuring?)) environment.
So basically Id have my containing my entire app lets say rendered, as is traditional, into "root" element. Except I want to inject a layer in that utilizes Three Fiber to render and everything I might want my site (or even just a particular component) to contain onto this plane. Allowing one to make a react site as normal and behind the scenes (probably in index.js or intermediate file) would instead of being rendered "flat" against the screen i could "tilt" the entire site, give it opacity, maybe have multiple webpages all able to be shuffled like cards, sides of a dice, w/e tf.
If anybody has any suggestions im struggling with how one could go about this.
Im worried i might have to get kind of low-level (which im not totally against), but was hopeful there was some support for something of this nature. So far ive tried even having simple elements like an image element inside a material (element - via three fiber) or inside the mesh element (where the material would go) to no avail. Im just beginning to get my hands dirty but google hasnt availed me much for this project, so I turned to good ol' stack overflow for my first personal request! 🤯 😲 👹 !
Thanks in advance so much for your time and consideration - cheers,
John Thummel
this is possible using drei/Html. some impressions:
https://twitter.com/0xca0a/status/1398633764931178498
https://twitter.com/0xca0a/status/1407758860203573251
I want to add an image carousel to a profile page, and allow the user to view the images in fullscreen mode thanks to a modal. It means - if I'm not mistaken - that the carousel will be imported twice: once in the profile component, and another one on top of it when the modal opens.
It is a heavy process, and I'm afraid of performance issues. I thought about creating my own carousel, but there are already many packages that perfectly deal with hand gestures on mobile, etc. However, their weight is sometimes dreadful.
For instance, the library react-awesome-slider - which seems perfect - weights 666kb! However, on Bundlephobia, it is supposed to only weight 36.2kb or 8.2kb gzipped. Who is right?
Will react-awesome-slider weight 2*666kb, 2*36.2kb or 2*8.2kb in my final bundle? What is the maximum weight recommended to keep a high level of fluidity/performance?
This looks like premature optimization. Don't care about your bundle size in this manner - if 3kb gzip is a lot or not. Simply, if you need that library use it. You will understand that having library for summarizing of two numbers might not be necessary before any bundle size issue will appear.
Bundle size that you always care about is the gzipped value, that's what client receives and has to "download" - that takes time. But as you can imagine, downloading 30kb on your computer at home is not an issue. On old device in middle of Blairwitch forest it might be.
Also, it gets send to client once per page/application so if your modal has it and your page has it it won't be included twice. Imagine having some library like Lodash, which is big and used (if I exaggerate) in every function, do you think it be included 100 times?
Try to optimize the user experience in terms of ui/ux, that will be the first one user will quit your page for, not that he had to download 30kb of carousel, he will not even notice!
We are very new to React JS. There are lots of debuts/confusions around what should be a component and what should not.
Is there any guideline available to make this decision simpler?
For Example, a button displayed many places across the site should be a single component? While attributes of the button like color, dimensions, action, label will be varying.
You don't have to decide ahead of time, "Oh, I'm going to reuse this so I'll make it a component." Usually you start with one component, and then break it up later: You start with a component, it gets bigger and bigger, you notice it's getting unwieldy or you've got identical code in places - so you refactor into multiple components.
DRY: When you find yourself repeating the same React code in multiple places, that's when you need a component.
Also, any time you have complicated logic that applies to only one part of your UI, that's another good time to separate it out. Otherwise you will end up with a big jumble of complexity.
I wondered the same thing when I started out. It becomes clearer as you work with React. Give it some time and don't be afraid to go back and refactor.
I'm fairly new to react, and really enjoying it. In creating components, is there a good rule of thumb (or simple generalization) to consider when deciding if a component should manage it's own state or not.
As example (only as example), an input that gets different classes added based on state, like 'hover', or 'not empty'...
Would it be better to create a component that manages those states internally or just handle that wherever I'm rendering an input?
I know this question may be 'primarily opinion based', but I'm hoping to get a general feel for how to think about it.
Thanks in advance,
-Ted
This is a constant internal battle that you'll just decide on down the line and you're right that it's primarily opinion based (meaning no answer will be correct). However, I can share my own experience and the process I take to decide on how to split the logic of my components.
I think of these things:
How will having/not having that piece of logic affect unit tests? If the component would need too much setup to be tested, then I move some logic into it and away from a parent Container component.
How often will I reuse the component? If it's many many times, then I look at the types of Container components that would render it and, again, if it seems like too much boilerplate is needed, then move the logic.
Does the value change through its own behavior or based on outside queues? In your example of the hover, the behavior changes due to its own behavior so it feels like the className (a prop of itself) is reacting to the component itself.
Most importantly, do you benefit from removing the logic and placing it in the Container? If you think that other component could benefit from knowing the hover state of your input field, then you may want to put the logic in the container. Otherwise you're abstracting away too much.
Application state management libraries such as Redux will often suggest to use their libraries as little as possible and instead rely on internal state of the component. I mention this because as you figure out where to put your logic, you have to think that about the end goal, which is usually to create a web application, with multiple components working together. Abstract too little and you end up creating non-reusable components. Abstract too much and you have tons of boilerplate and configuration lying around that could be trimmed by using internal state.
Zeke has some absolutely great points. I'd just like to add my own guideline, which is:
If the behavior of the component is the same, no matter where it's used, and is not tied to the behavior of the app/environment at large, then state should be internal
otherwise, manage state elsewhere and pass in props
my premise was wrong. while AngularJS was certainly slowing things down, it was not due to the problem I describe below. however, it was flim's answer to my question - how to exclude an element from an Angular scope - that was able to prove this.
I'm building a site that generates graphs using d3+Raphael from AJAX-fetched data. this results in a LOT of SVG or VML elements in the DOM, depending on what type of chart the user chooses to render (pie has few, line and stacked bar have many, for example).
I'm running into a problem where entering text into text fields controlled by AngularJS brings Firefox to a crawl. I type a few characters, then wait 2-3 seconds for them to suddenly appear, then type a few more, etc. (Chrome seems to handle this a bit better.)
when there is no graph on the page (the user has not provided enough data for one to be generated), editing the contents of these text fields is fine. I assume AngularJS is having trouble when it tries to update the DOM and there's hundreds SVG or VML elements it has to look through.
the graph, however, contains nothing that AngularJS need worry itself with. (there are, however, UI elements both before and after the graph that it DOES need to pay attention to.)
I can think of two solutions:
put the graph's DIV outside the AngularJS controller, and use CSS to position it where it's actually wanted
tell AngularJS - somehow - to nevermind the graph's DIV; to skip it over when keeping the view and model in-sync
the second option seems preferable to me, since it keeps the document layout sane/semantic. is there any way to do this? (or some, even-better solution I have not thought of?)
Have you tried ng-non-bindable? http://docs.angularjs.org/api/ng.directive:ngNonBindable
<ANY ng-non-bindable>
...
</ANY>