I am in the process of learning ReactJS (NextJS) with Material UI. Currently i am trying to figure out, the best way to implement "interconnected lists". My idea is, to represent a hierarchy with n levels in n different lists side by side.
What would be the best approach for something like this? All i can think of is a huge mess off callbacks all over the place in one main file which coordinates everything, with one callback to the 1st list rendering the second list and the 2nd list rendering the 3rd list etc.
Note that i am new to JavaScript and to WebDev in general. I would only like to know, if that's the way to go or if there is an easier, simpler way.
Related
I'm sure this has probably been asked before, but I'm fairly new to threejs (and React Fiber), so part of my problem here is not really knowing how to phrase what I need..
I know what I want to do must be possible, because it is possible to drag and drop any gltf file here: https://gltf-viewer.donmccurdy.com/ and see it rendered correctly.
So, what I want to do, is create a loop which will traverse all parts (nodes?) of a gltf model with/without animations (such as this one) and output it as part of a webpage.
Currently, I find myself tediously trying to add a <mesh> for each and every part of a model, and I know there must be an easier way.
I have found the source-code for the viewer here, but as mentioned, I'm still quite new to this library, so any help (or link to a similar question), would be appreciated.
I'm running into a problem in React. As shown in the figure below, if there are many elements in a list, such as 100 elements, then use a component to render the view of each element in a For loop, and the web page will take several seconds to completely rendering, and no operations can be performed during rendering.
Figure 1
I think it's because the entire rendering process occupies the main process, and that lead to program cannot respond before completely rendering.
In order to improve page generation efficiency and response time, I came up with a compromise solution. As shown in the figure below, we first render the placeholder image of the entire list according to the number of lists in advance, and then render the real data one by one according to the order.
Figure 2
As shown in the figure below, for example, we have 100 elements, then render 100 empty divs or placeholders first, and then render a real element every 100/200 milliseconds.
Figure 3
Finally, after N renderings, the effect shown below will be formed. Of course, it's best to do so that only the placeholders that the user sees will render the real data.
Figure 4
Back to question, I am very unfamiliar with React, can I do this with React? Is there a corresponding library that can be used in React?
You've tagged reactjs, and react-native. Is this for react on the web or React Native?
If React Native then the FlatList component can help rather than rendering via a loop since FlatList supports lazy loading which would help with loading not all at once.
For web the recommended approach is to use react-window or react-virtualized as documented here.
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'm currently working on a flutter application. I have a file with a big widget tree. In order to easier understand, read and maintain I wanted to "crop" the widget tree.
First what I did was to create multiple functions, which represented a bigger part of the tree such as _createFancyImage() or _createFancyContainer. After some research, I found out that such a design has some downsides (see: https://github.com/flutter/flutter/issues/19269). So then I decided to create StatelessWidgets instead. Because of the huge size of the widget tree, I broke it down to 3 logical StatelessWidgets. Now I can use FancyImage() or FancyContainer() which represent each a standalone widget.
As a beginner, I'm not sure whether I should keep those StatelessWidgetclasses within the same file. Alternatively, I could create independent files. One thing to clarify: I'm not using those fancy widgets somewhere else. Those are unique to this one big widget tree otherwise I could have outsourced them into a new folder such as "common_widgets" or "components".
Unfortunately, I couldn't find something within the Dart and Flutter Repo style guides nor on the internet.
I appreciate every suggestion.
You can add as much classes as you need in a single file. It depends on the developer's mindset.
But, let say if one of your class can be reused by other classes or packages then you should add it to another file for better separation.
I can favour you one approach is that your each file should have maximum one Stateful widget and as many Stateless widgets as you want for that corresponding widget will be a better scenario.
Still in some cases if you feel that more than enough stateless widgets has been added in a single file you should separate it in another file based on your choice.
I prefer to keep one public widget which having the same name as the filename and remaining private widgets.
comming to your ques is How many widgets in a single file?
Its actually depend there is no such rule to restrict the limit of file. Different authors having different preference. I prefer try to keep 5-6 classes(widgets) and
each one having 5-6 functions.
Try to make a file single responsible i.e(5-6 classes together responsible for single functionality). Don't make god class which having unrelated concerns together later it will pains(haha)
If it's a common widget keep them separate to respect DRY principle(Don't repeat yourself)
If the widget is further divided into 3-4 widgets or it children widget change depend upon rest response keep seprate for good practise
Bonus Tip: try using code folding shortcuts to push a little more
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.