Let's assume I need to change the behaviour or the CSS style of a Nebular/NGX-admin component. What should I do ?
What I reached so far is to change the module directly in node_modules/#nebular but I'm not sure this is a best practice.
Is there a workaround ?
Yea it's an interesting question. I am using Nebular at one of my admin panels in production. And the most problems which you will get after modification of basic styles will touch you when you will try to update the version of Nebular/NGX-admin.
So my advice for you to keep all your customized styles in some separate file in root or #theme. Something like nebular-custom.scss. In this case, you will be able to separate your styles before the update.
But keep in mind that similar problems you can get if you will write your Components code in wrong places in the file structure. So, first of all, try not to change and not to write your Components in the #core module. Better do it in some separate module or at least folder. Also, nice practice will be to write all your http and model layers in the #data module.
After all, you should be able to update Nebular/NGX-admin with replacing #core and #theme modules with facing some minor issues.
Related
I'm working on a structure for a React application. We have ./src/Assets/Images folder, but should I put all component assets there? or I should put each component's assets to it's folder?
I mean: ./src/Components/Loading/animation.gif
or: ./src/Assets/Images/animation.gif
I'm actually interested to design a maintainable and clear structure for this app.
What do you think? which pattern is better for development and the feature...
You know, I've separated Styles but have doubt on Images??
This must be an opinion based question and it isn't something you should care that much about to be honest. It's personal preference but if you ask me, it's better to keep you assets in a same folder so your components' structure won't get messy.
I would like to say "all in one place" is good. Assets that are required to be loaded, for example images for navigation should be placed in public folder as it is much more comfortable to use. You just need to set url to point it.
For other cases, I think it is better to place it in component's folder.
I think tree structure is easy to maintain and scalable. Let's imagine that you need to update a component. In that case, you just need to update files in the same folder. If it is located somewhere else, this can lead to potential problems: for example, you need to make sure that it is not used by other files.
To sum up, I think it is good to place assets in the component's folder.
I'm getting started with React and I'm having a hard time wrapping my head around the actual "flow" of a project.
I've googled and searched around on this site regarding the structure or architecture of a React app, but most of them address file structure and often end with some variant of "There's no one right way to structure the files".
But I'm looking for something more high level than that. I'm just trying to grasp how all the pieces React provides fit together. I can't even begin worrying about how I organize my files if I don't even know entirely how each file relates to one another.
As an example of what I mean - when working with an MVC app, you have three "high level" components: model, view, and controller. Their purposes and relationships to each other are distinct. A view handles the display, a model handles the data, a controller handles the connection between them. You can find easy reference diagrams to keep track of this organization.
Of course React isn't it's own paradigm, and I know it's entirely focused on front-end, but I'm curious if there's a similar way of describing the pieces of a typical React app. How containers, components, reducers, actions, etc. all work together to make an end result.
I would agree with Marko Grešak's comment. You learn as you do and understand the code.
But, if you fill lost (which I was also), I can tell you about some architectures I saw :
A teacher of mine split the logic and the view. In one folder, you find your components, in one folder, classic JS classes that contains all the functions that handle the logic behind what the components print. Each component imported its own css file, with only the styles for this one component. We used this with MobX..
At work, we have a js folder, containing a components folder, for components that are at the 'end of the line', a containers folder, for components that have other components in them, a store folder for everything Redux, an asset folder for images and such, and a utility folder for other functions we might want to call. At the same level as the js folder, we have a sass folder. This is in no way a 'correct' or 'recommanded' way of doing things.
In general, you'll find a lot of tutorials and other things referring to dumb and smart components - splitting between the ones that just receive props and print them, and the ones accessing data and manipulating it. It's a bit like our container/component system in the end.
In the end, you're free to do how you want. Just try to keep a certain logic in how you split things so that it makes sense overall, but there is no set rules.
What are the disadvantages of using one big React component?
I have a deep experience using webpack, browserify, AngularJS, ES6, NPM and other similar web framework. I am new to React.
I want to create a single page app in React. I don't want or need testing. I don't need team friends to work on. I only need to make the product development as fast as possible. Make thing works. You can call it MVP. You can call it type lessm, or smart developement. If things work good in the future I can consider refactoring the project. I am the only developer who works on. I don't worry about perfromance issue (if it is just few ms)
The question is: All the articles said to make as much as possible many and small React components. In separate files. You can see the React-Starter-Kit. It is huge.
You can see that every component is a separate file.There is huge webpack.config.js file. Every component import many other things. If I also want Redux, I need to import the store, and make connect on every component.
I want to take different approach. I want to use React & Redux. But using only one component. Every inner element can Dispatch or execute events.
Is there is any problems in the future that I don't think about?
HTML:
<html><head><body></body></html>
JavaScript:
App=React.createClass(function(){
getInitialState:function(){
return {
openMore:'block'
}
},
openMore:function(){
this.setState({openMore:'visible'})
},
render:function(){
return (
<div>
I want to put all the HTML of the app
<span>
In one component that do everything.
<button onClick={this.openMore}>More Info</button>
<span> This way I beleive I will need to type less for development</span>
<b style={{display:this.getState().openMore}}>What are the disadvance of this?</b>
</span>
</div>
)
}
})
ReactDOM.render(App,document.getElementsByTagName('body')[0])
Well disadvantages are many. I will try listing them from what I have faced and observed:-
React was built on the concept to break page into components, so yeah the more you break the page into small components the more it is easier to use.
Its generally easy to track the code.
Its scalable
One component does not break other components.
Re-rendering is there only for specified components if they are isolated. If you have everything in a single component, the rendering would make your entire component load again, reducing efficiency.
Harder to test
Difficult to use with redux while passing actions and then connecting to store.
Your component should do only one job.
Cannot break the components into presentational and container components thus not utilising redux to full potential.
Not being able to use code spilt feature of webpack which increase speed of page due to partial code loading.
These are few things I personally faced. Next,coming to webpack configuration. I hardly have configured webpack file more than 100 lines and trust me those 100 lines make your life really easier. In fact basic configuration is just 10-15 lines which can generate your bundle.
Now,coming to problems in future, yes following would be problems:-
Difficult to scale up.
Difficult to test
Not utilising libraries to their potential
Difficult to manage component due to monolith behavior.
Hope it helps!!!
Having a single large file is fine. React was built on the maxims "No abstraction is better than the wrong abstraction" and having an API with a low surface area.
If you're not sure what problems your application is solving, then wait until you feel the pain of not having an abstractions before you create one.
If your application is likely to be in flux as its feature set isn't nailed down, then don't give yourself busy work by moving things around in different files.
If you don't have a website that is designed with reusable components that are intuitively separable, than don't separate it out into different components.
It is fine to use React just as a means of having a declarative syntax for what your html should look like in different states.
Having large components is bad due that you cannot simplify your code. Splitting your modules into smaller ones, will make it easier for you to maintain the code at a longer term, as well as finding out an error faster. Stack Trace is easier as well as it is more composeable, when having an implicit component.
FWIW, you can do a lot more separating your component into smaller ones, such as filtered props and an own state. The bad thing though, is that you can loose track of how the application is built up when you are looking at the build others have made.
I'm using ui-router/stateProvider to load various views for a single page app. Additionally I'm following what appears to be best practice for structuring code by breaking my code into components so I have, for example;
Index.html
\Components
\Component1
\page1.html
\page1.css
\page1-controllers.js
\page1-directives.js
\Component2
\page2.html
\page2.css
\page2-controllers.js
\page2-directives.js
I have quite a few different views/components (10+) and my question really relates to how to manage the loading of the js files (and the CSS files for that matter). I can put the JS files all in tags in the index.html file and all works fine, but looks a bit messy as it is a very long list.
So my question is: How should I manage the inclusion of the various scripts for each view; should they all remain in the index.html file or is there a better way of managing them, such as loading only when each view is called via the ui-router?
Many Thanks
I think that you need to use RequireJs, I will include a couple of sites with the documentation that explain how implement that.
http://www.javascripthtml.com/load-dynamically-javascript-file-in-angularjs-with-requirejs/
https://cdnjs.com/libraries/backbone.js/tutorials/organizing-backbone-using-modules
For css you may want to add a single class to each view then use a single css file for all views. I keep the css organized into modules for easy access. This will also help load times as it will require less requests.
For js I would create a universal js file that contains any code that is required for ALL views, then create individual js files for individual views. There really isn't a "right" way per se but preferred ways depending on the developers you work with. Keep it simple and easy for other developers to read. :)
I have the same problem as you, I think that the only solution for us is to add the script in the "index.hmtl" page.
I'm developing a CakePHP application that we will provide as a white label for people to implement for their own companies, and they'll need to have certain customization capabilities for themselves.
For starters, they'll be able to do anything they want with the views, and they can add their own Controllers/Models if they need to add completely new stuff. However, I'd rather advise against touching my controllers and models, to make version upgrading easier.
Esentially, the customization capabilities I'm planning to give them are going to be quite basic, I just need to call "something" when certain things happen, so they can do things like update external systems, e-mail themselves/the clients, things like that.
I'm wondering what's the best way to do this?
My plan is to have a "file" (with one class) for each controller of mine, to keep things reasonably organized. This file will have a bunch of empty methods that my code will call, and they'll be able to add code inside those methods to do whatever they need to do.
The specific question is, should this class full of empty methods be a Component? A Controller? Just a regular plain PHP class?
I'll need to call methods in this class from my Controllers, so I'm guessing making it a Controller is out of the question (unless maybe it's a controller that inherits from mine? or mine inherits from theirs, probably).
Also, I'd need the implementer of these methods to have access to my Models and Components, although I'm ok with making them use App::Import, I don't need to have the magic $this->ModelName members set.
Also, does this file I create (etiher Component or Controller) have to live in the app folder next to the other (my) controllers/components? Or can I throw it somewhere separate like the vendors folder?
Have you done something like this before?
Any tips/advice/pitfalls to avoid will be more than welcome.
I know this is kind of subjective, I'm looking to hear from your experience mostly, if you've done this before.
Thanks!
Two ideas that spring to mind:
create abstract templates (controllers, models, whatever necessary) that your clients can extend
write your controllers/components/models as a plugin within their own namespace
Ultimately you seem to want to provide an "enhanced" Cake framework, that your clients still have to write their own Cake code in (I don't know how this goes together with your idea of "basic customization capabilities" though). As such, you should write your code in as much an "optional" manner as possible (namespaced plugins, components, AppModel enhancements, extra libs) and provide documentation on how to use these to help your clients speed up their work.
I would setup a common set of events and use something like the linked to event system to handle this.
That lets the clients manage the event handler classes (read the readme to see what I mean) and subscribe to and broadcast events application-wide.
Also - if you want to have your users not muck about with your core functionality I recommend you package your main app as a plugin.
http://github.com/m3nt0r/eventful-cakephp