Mimicking three and examples folder #116
Replies: 4 comments
-
Hi @swingingtom, |
Beta Was this translation helpful? Give feedback.
-
As I can interpret it, right now the current state of example folder contains different purposes :
And something like #121 or https://user-images.githubusercontent.com/2693840/150170272-742e07e4-6289-45a9-bb04-299583b3303b.png which is really useful when developing or debugging a feature doesn't really fit in any of the previous cases. It might even be unproductive to publish them to users.
I think you are right about your concern. Maybe just a flag on example to tell published or not might do the trick? Maybe using a gui library and discarding it inside webpack build command ( |
Beta Was this translation helpful? Give feedback.
-
@felixmariotto I started the branch Uniformized importsIt tries to uniformize code written witin examples directory with what users code would have to be : // unstandardized imports
import ThreeMeshUI from '../src/three-mesh-ui.js';
//standardized imports
import ThreeMeshUI from 'three-mesh-ui'; The same is done with pieces of code located within the examples directory // unstandardized imports
import VRControl from './utils/VRControl.js';
//standardized imports
import ThreeMeshUI from 'three-mesh-ui/examples/controls/VRControl.js'; The suggestion in this PR is to use webpack aliases to do so //webpack.prod.config.js
[...]
resolve: {
alias: {
"three-mesh-ui/examples": path.resolve(__dirname, '../examples/'),
"three-mesh-ui": path.resolve(__dirname, '../src/three-mesh-ui.js'),
},
}, Categorizing examplesUsing webpack.prod.config , we could categorize any root example js files into different categories :
Built-in examples componentsSome examples create locally components that are really handy, and could be available to build more examples without having to copy/paste. Users could rely on those to use them as-is, or rely on those component code to have an examples on how components can be made using three-mesh-ui core components combinaisons. Developers could rely on them to provide mode interactive feature demonstrations or workbenches. Ui/Buttons. They comes from an example, but could be used in more than one examples. A 'ui' folder with more built-in ui components examples could be great. Same goes for VRControl and Raycaster. Raycaster is used a two locations with different implementations (Buttons & Keyboard) |
Beta Was this translation helpful? Give feedback.
-
Some toughts on UI/Interactive componentsJS / JSMCurrently all suggested components are jsm only. Not sure it worth to also support js, but Im clearly biaised. Keyboard
States vs Styles for interactive components ( cumulative states )If you look at the "Toggle Buttons" in the "interactive_components" page, it suffers from what I would call "100% relying on states". While clicking a button, it doesnt get green until we roll over it. Because 'hovered' and 'selected' should be cumulative. We could build ui components with "styles" properties instead of "states", and internally in ui components, redefining "states" according to cumulative states. If the component is selected => lets redefined its hovered state with : hovered style overwritten by any selected style properties. States triggering ( naming convention )Actions requested by raycaster could be present tense. Ui component would compute its state. Raycaster 'select' => Ui component if can be selected => 'selected' Event triggeringUnfortunately I based the branch components upon the raycaster of button, and raycaster of keyboard looked a bit more of what I would had need. But internally, a component could use its x latest states to know what state to trigger. Raycaster 'select' => Ui component if latest states are ['idle','hovered'] => click NextThose draft component weren't that difficult to built, but their current state are far from being completed. Having more discussed basis would easy their refactor. If you agree with. Side noteWhy do we have contentAlign "left,top,bottom,right" instead of "start,end"? I got a lot of wrong alignment issues. |
Beta Was this translation helpful? Give feedback.
-
Hey community,
with such features as #1 Text Selection , #114 Best Fit, #113 computeUV2 , wouldn't be a structure like an examples folder be interesting?
New features like effects, controls, behaviour could be out of
ThreeMeshUI
global object, and loaded only we project requires it.This could reduce the bundle size, and keeps core from "not so frequent case" code complexity.
Beta Was this translation helpful? Give feedback.
All reactions