I'm wanting some advice/opinions about react component usage.
When faced with two different designs for the desktop and mobile version (NOT an app) of a site, do you use the same components and modify various parts using media queries or JavaScript window size etc OR do you create different components where required and render differently if it's the mobile site?
Any strategies you have used with your experience/opinions on would be of great help. Many different ones will be appreciated!
Thanks!
I would use the webs standard of responsive design and libraries like bootstrap or foundation. There is no need to write different views unless you are targeting different platforms (native vs web for example). This will save you time and effort as the gains you get from writing different components are not substantial.
That said if there are particular pages that would be better served with completely different UI you can do a mix of both. There is no advantage in simply creating two home pages that have a bunch of text, this issue has been solved by responsive design practices and not taking advantage of them is a step backwards.
Also take advantage of component re use as much as you can. If desktop shares 5/6 features write the 5 in a way they can scale differently to be shred and write two versions of the 6th.
I wouldn't say that the two options are mutually exclusive. Take advantage of responsive design practices when you can and take advantage of the componentization of react when you can. If you ever find yourself not sure which way to go it likely means use responsive design (IMHO).
I have designed apps where the target was truly different platforms. We wanted to have native and web side by side. What you are looking for is a middle ground as many components will likely be shared but a handful may require different functionality and thus components. I have seen two app structures, one that organizes your app by type (components vs containers for example) and another that organized code based on page structure (index, account, login, shared). I have found that when needing to mix components that accomplish the same function but target different platforms its best to separate by page structure as in the index page I can simply have a iOS index and a web index side by side when needed. This allows me to have two stateless components and one stageful container to power them. This also makes more sense mentally for larger apps and allows you to do more of what you are looking to do.
Overall, if you are needing to use if statements to hide and show functionality consider breaking things down into reusable components and create a mobile and desktop presentational component being powered by a single state full component.
Related
I am trying to architect an extendable Web applications that allows users to build and export static websites. Similar to this site and this site, except developers can build their own custom components using HTML,CSS and Javascript and add it to the public library.
The Architecture must:
Ensure that user added components can not interfere with each other (Encapsulation)
HTML attributes have unique values (<div id="a"> remains unique to this component)
CSS is namespaced
Javascript objects are scoped and can only modify DOM elements within this component.
Enable developers to build components in simple HTML, CSS, Javascript without the need for building a React/Vue/Angular etc. JS components.
Developers can build components without worrying about encapsulation issues above. i.e. The application transforms the unsafe HTML,CSS,Javascript to one which is safe.
Ensures cross-browser compatibility
iFrames provide excellent encapsulation but have performance and device scaling issues. I have been reading about Shadow DOM, Web components but haven't been able to figure out the correct approach to build such a Web Application.
I also came across this SO Question but it seems like this is more geared toward back-end. Please correct me if I am wrong. Is there any existing framework/build tools/library that I can use? If not how should I go about building such a tool?
I have developed some SAPUI5 mobile apps and I'd like to merge them into a portal (with tiles) so I can switch between them as a "reputation".
Now I would like to know, what would be the "best" way to implement this case?
At the moment the apps have got a controller and views. My first idea was to build a "portal-app" which includes all the views of the other apps with an own controller but then I noticed that the performance has decreased (because all resources (OData-models etc.) load when starting the portal-app).
I also tried to link them (all with their own index.html) but this case seems not to be the right one.
So is there a way to load the views dynamicly or a whole app and how can I do that?
First of all, SAP's official solution for this problem is called SAP Fiori Launchpad. However, it's much more complex to set up (you need an underlying application server which holds SAP Fiori. You need to handle user roles and assign applications to roles). However, it's great for inspiration. (Here you can check it)
You can create a separate component which holds the references to other applications. Your applications can be referenced from Tiles.
I don't know the current implementation of your applications, but it's recommended to implement them as components (UI components if they have visual representation).
With components, you will be able to use Routing (navigating between views, or even components using hashes (urls)), which helps you to manage resources and services properly. With this you can prevent unwanted odata requests as well.
It can be a big step forward from a simple application architecture, but it's worth it.
Of course, you can implement one simple application without components. In this case you can experience the mentioned performance issues. Consider to move data intensive operations into event handlers and perform these tasks asynchronously.
We're impressed with the integration and best practices that BoilerplateJS provides but the documentation is definitely lacking, especially for new RequireJS users.
We're a team of 5, each with different skill sets and one of the attractive points of BoilerplateJS is the ability to isolate UI components.
From the sample scaffolding, it's clear how we can unit-test each component separately. However, we're unclear how we can do this during development:
Developer A creates component structure and view model (tested) and passes it to Developer B
Developer B develops CSS and possibly animation for the component
Developer A and/or B integrate the component into the rest of the website and further test integration
How is it possible to achieve (2)? i.e. allow designers and developers to work on an isolated component - what is the recommended way to load the component so it can developed/debugged/tested?
About CSS
A UI component has roughly 3 parts: Structure (HTML), Presentation (CSS), Behavior (JS). A common way of handling is developers focusing on the Structure and Logic where designers work on the presentation.
This is how we developed the sample application of boilerplatejs. For example, the Menu, Theme and Localization components were developed by developers as a simple 'unordered lists' which looked like below exactly when they completed it (just delete the theme css link via Chrome Developer Tools and you will see the same):
Then designers took the ugly UI and created a theme that position and render these lists in a professional manner (we developed 2 themes stored at src/modules/baseModule/theme). It is of course hard for the developers to just deliver something that ugly, but they need to trust the ability of the designers to do their job. I'm sure you use a source control tool that allows different team members to work on the same component even simultaneously.
If you want the theming to be a prominent feature, I recommend minimizing component specific CSS files. Otherwise you might not be able to create different themes that completely changes the layout and look-n-feel of your components. Downside of not having component local css is the fact that components are not really self contained without 'presentation'. I'm still struggling to answer this question properly, any ideas/help is appreciated! See my related question on this below:
global CSS theming combination with component specific local stylesheets
Anyway there are several ways you may add CSS to your components, have a look at this question where these different ways are discussed.
Adding external CSS file to a BoilerplateJS project
Now about embedding components...
If you want the components embedded in to some other webpage, you can use the DOMController of boilerplate for that. For example, lets say you need to embed the 'departments (src/modules/sampleModule1/departments)' component to some other website. You will have to add a DomController in addition to already existing UrlController (UrlController respond to browser URL changes) to the module (src/modules/sampleModule1/module.js).
//crate a dom controller that searchs within whole document body
var domController = new Boiler.DomController($("body"));
domController.addRoutes({
//look for elements with id 'department_comp' and embed the department component
'#department_comp' : new DepartmentComponent(context),
});
domController.start();
Now on your webpage or on external site place a div or a section element for the DomController to embed department.
<section id="department_comp"></section>
Of course there are two things you need to take care of:
1) Your web page needs to have boilerplatejs runtime in it. This means all your third party JS libraries and theme CSS file should be statically added to the web page. (We are working around this, with v0.2-stable we expect to release a bootstrapper that can do all that with a single script declaration)
2) If your component uses JSON services from a different domain, you will have to address cross domain HTTP requests either with JSONp or CORS. But if your REST services are hosted on the same domain, you dont have to worry about this.
I have an app that is mostly traditional static HTML pages linked via anchor tags, but lately I've been adding more and more dynamic behavior using JS.
I need to "juggle" between numerous UI states in the form of hiding/showing/creating different elements for every "screen". (Let's say homepage and fullpage blog post.)
If I have only 2 states it's pretty easy but complexity arises as more and more "screens" are added.
The question:
How would I organize the various UI states so that it is straightforward to switch between?
If you're running into a lot of complexity managing your UI state, it may well be a sign that app logic is too tightly coupled with UI handling. This is especially noticeable if there are places where you need to inspect the state of the UI to make decisions about how the app logic should react.
As it gets more complex you may want to consider decoupling the UI using some kind of MVC pattern. Or even better, using a pre-rolled framework such as Knockout.js.
Note: Other frameworks are available
I would use JavaScriptMVC it's a lightweight framework that has had a fair bit of work put into it the past year or so . By having a client side mvc you could set up two different views and alternate between them with ease .
You may also want to look into sproutcore
What should I use to manage growing number of JavaScript files in my application?
We are building a django application with several apps. Each app has different functionality, and has to be rendered in three different modes (pc, tablet, mobile). There is a lot of things happening in JavaScript: managing data received from the server, handling user events, injecting HTML snippets, and loading sub-components. Some of the functinality is shared between apps and view modes, but often it makes sense to write a specific functions (for example, hover and click events may have to be handled differently on a PC layout vs. a tablet layout) so we are grouping this in files based on app/layout/function.
Up to a point we were using a flat file structure with naming to differentiate types of files:
ui.common.js
ui.app1.pc.handlers.js
ui.app1.pc.domManupulators.js
ui.app1.tablet.js
ui.app2.pc.js
...
Right now, however, as the number of apps (and corner cases) grows this way is fast becoming unusuable (we're approaching 20+ files and expecting maybe 40+ by the time we're done), so we are putting everything in directories like so:
js/
common/
core1.js
ajax2.js
app1/
tablet.js
pc.js
app2/
mobile.js
...
I have been looking at JavaScriptMVC to help with this. While it does offer useful tools it doesn't seem to have anything that would specifically make managing our giant JavaScript library better. We are expanding our dev team soon and code maintainability is very important.
Is there something that may make our life easier? Are there any habits/rules of thumb you use in your work that could alleviate this?
Backbone.js is used to organize javascript heavy applications in an MVC-style pattern. It's going to take some learning, but it's definitely something you'll want to look into and learn a bit about even if you don't end up using it.
It's used on quite a few pretty impressive projects
And, here's a site to learn more with tutorials.
Typically, grouping libraries by commonality (like your second example) would be preferred. However, more importantly would be making sure you have namespaced or otherwise make them unique so that you are unlikely to get naming collisions with other potential scripts.