Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Let's assume that I am a decent JS programmer. I can easily do React.js development. I also can write HTML and CSS to some extent. I cannot, however, build a webpage from the ground up, i.e. define the HTML structure (say in terms of React components or just plain HTML), add some CSS and get the all-shiny responsive modern-looking fancy webpage. So, I work with a designer, who uses some sort of black magic (or maybe a WYSIWYG tool, or a service like wix.com) to prototype a web page.
So, what I get is a bunch of html files, images, css styles and maybe a bit of javascript.
Now I need to convert all this into a component hierarchy of React. I'm sure I can do this, and after the job is done, I get a shiny new website, beautiful from the technological and aesthetical point of view.
However, we all know that we work in Agile environments. Later on, a designer wants me to change something. 'Add a black border' he says. And here things go out of control.
Should I do this (manually look up the style in css and add a border)? What if changes required are more complicated? Like swap a header and a footer?
Should he do this? (regenerate those source htmls/css/images again) What happens after that? Should I diff the whole website to learn what have changed and reimplement the whole component structure to reflect changes?
Are there any accepted methodologies to solve this evil circle? Maybe a tool that maps the input ugly html code to the properly done React code?
Or maybe I am totally wrong and I should learn the art of design myself?
Edit: Ok, as everybody is misundestanding the question, here is the shorter version. If the Templater changes the templates already implemented in React site, what can I do except manually diff and patch all the changes to the source css/html files?
What you're sounds a bit sketchy to me. You have to know CSS and HTML if you want to build a website, and especially maintain it. The designer probably won't be here forever for you and you would end-up in a difficult position.
The kind of flow you describe, where the designers creates all the structure and gives you the full html and css code was only working in the age of jQuery. The plug of your scripts were pretty easy and didn't required much changes, since it was decoupled from the actual html and you would use dom ids for the targeting.
How it works at Uber, but I'm sure in a lot of other companies, is that the designer is in charge of the design, but that's it, the rest is up to you. You have to make a second pass after him for the actual implementation.
Since reproduction can be pretty difficult and approximative, you can use Invision, where the designer will create the mockups, but you as a developer can get all the css properties of an element, making the integration much easier to do (dunno if wix has the same kind of feature).
If your designer updates a part of the design, it becomes straight-forward for you to know what changed and what component needs to be updated. That's one of the benefits of owning the code rather than taking one from someone else (especially if it was automatically generated).
Get the html files
Create the Router in React
Migrate the basic Layout stuff into a Layout Component
Migrate the pages content into PagesComponents
Migrate common components into your ComponentsLibrary (Navs, Buttons, etc.)
Replace the common html parts with the newly created Components
Apply logic, and so on. Refactoring, refactoring, refactoring... :)
Usually, I am asking the Templater/HTML to put their work into ReactComponents, for this I setup a simple empty React Application, with Routes definitions, and work with them, it will definitely save you a lot of time, because you can apply some logic in parallel or rethink some parts of your application, and ask for changes.
To be real efficient, they should just start by creating a pure-components library, where every component and the styles for it are isolated from the rest of the application, let them put the default values inside, and then let them use props, after the pure components are done, you can orchestrate your application with containers and logic.
The first flow you mentioned is OK, when you get only plane html and css pages from the designer/html coder.
If you are planing to create those pages with react/angular/vue whatever...
you don't need any javascript from the designer.
The steps you will need to take:
1) get html and css from designer
2) design on paper your blocks to components: header, navbar, sidebar, mainContent, footer, PostsList, Post, CommentsList, Comment, etc
3) Start building those components one by one
*Let's assume we are using react
4) make sure each component is stand alone, and extensible, for easy update in the future.
5) Make sure you have tests! Learn TDD
6) ship your app
Next cycles for updates...
1) Your designer gives you new designed pages
2) you can use the designer html and css *PARTLY and use that in your code
3) make sure you extend your components or update properly
4) tests should still work properly
Some notes before you start diving in to all that work:
learn html, css and how to build simple pages properly
you can try bootstrap it is super easy to use
learn react (if thats is what you want to use)
you will need to build your code, so you will need webpack or whatever tool.
But there is much more work ahead, so good luck it's fun! :)
This sounds like a question somebody coming from a php programming background wokring with templates would ask. React works very differently and if you wanted to be in a position where you had a base site and wanted to make changes to it going forwards you would need to have a development environment setup so that once you have made your changes, you would then 'run a build' which would produce your bundled minified javascript file, from the source code in your development environment, ready for production which you would then push to the server as you would with any site.
The reason working like this is considered the way forward is becuase it is so easy to decouple your sites logic from its aestetic. So adding a border to an element becomes as easy as adding a line of css, running your build, uploading the latest version of your app to the server and its done. As long as its written correctly to begin with you should be able to work with confidence that a visual change will only affect your site visually. Changing a classname or moving an element wont break the logic because the logic should be either in your store/actions (redux/flux store method) or local to your components code (functional component).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
We are trying to develop a workflow, utilizing React react-sketchapp Sketch, that a designer in Sketch can produce React components and the coding (at least for the CSS) is automatically generated and configurable. There doesn't seem to be a lot of documentation and/or support.
We understand the basics of developing a component in React to Sketch, but has anyone figured out a workflow for the reverse? Any additional thoughts or documentation that could help?
We are thinking of dropping react-sketchapp and going to a more effective workflow
We have spent much time on this problem, so we can share some experience we have learned during product development.
First at all, the react-sketchapp is "react to sketch" direction, not sketch to react.
For sketch to react problem, the hardest things we found are
the difference of tree structure between sketch & react code
Designer focus on the visual, and won't care about the item structure, but engineers DO care about the structure of the DOM because it's designed for dynamic layout and resizable
So our way is to use some smart algorithm (or AI in the future) with little human intervention. Sometimes it's really hard to decide because there might be different right answers in terms of layout
the description or settings for the resizing layout
Sketch (the design tool) won't have any concept and hint about the layout (especially the relationship among children). So sometimes engineers are required to discuss with designer the exact behaviors while the component is resizing.
So it's required a way to convert the structure into some kinds of settings of layout. After trying, our suggestions would be CSS flex and grid. Because flex and grid provide great flexibility for positioning and be widely used and recognized by frontend engineers, also with high browser compatibility.
These two issues above are hard to be automated 100%, but after several iterations, we think it can be done 70% automated with some algorithms and a little human intervention. The generated code would be useful with right layout structure. After that, it could be improved to better code by applying some code optimization (shared style, better naming, simplified css/code, ...etc) which is easier to resolve.
I've been working with this concept (Sketch to React translation) and haven't found an effective/configurable solution and I don't think there will be any time soon, or at least one that put to use the best parts of Sketch with the best parts of React.
Sketch has an amazing symbol system that allows for design tokens (such as a global color palette or typography styles) to be re-used or instanced from a central location – a source of truth.
Unfortunate circumstance 1: These symbols sets do not translate over into variable sets (CSS or SCSS, etc.) when exported into a React component – all the values are hard coded and no variables are present. You may be able to create a very custom implementation to do this, but it will most certainly break the second you reconfigure your build process or tech stack choices.
Unfortunate circumstance 2: Sketch symbols or UI elements don't manage their own state, you simple swap them out with a different symbol/element. There's far too much involved to translate multiple sketch elements into the logic of a React component that manages it's own state. Especially when you take into account the complexity of modern build streams and technology stacks.
How my team has worked around this:
Shared building blocks and standards that bridge the gap between design and development can REALLY help. (An example is a set of CSS color variables that maps to a set of Sketch color symbols). Atomic level pieces of a system can be translated between Sketch and CSS with relative ease – then all you have to do is put the puzzle pieces together. Put this together with a good layer of communication between designers and developers, and your team is far ahead of the margins.
Given there is a React project that uses plain javascript, is there a way to use typescript partially only to define models?
So, lets say there are a few models that map to server responses, can only those be defined in typescript while the rest of the project remains in javascript.
If its possible, how to do it?
Typescript can definitely be implemented gradually into an existing JS project, and I know a few people who have gone through the process on some monoliths, it can be a really boring process but usually low risk.
I'll link you straight away to this:
https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html
The key is to understand what your goal is, and how to set everything up properly to accommodate for it, as you go it's as simple as toggling a few settings to unblock/check work as you go.
As for your question about some files being JS and some being TS, typescript handles pure JS perfectly fine, so you can switch every file to TS and even if it's pure js there won't be an issue :)
Have a read and if you need any more help on some specifics feel free to comment
I want to use ReactJS for the front end of our new system.
The back end system (in C#) has different modules which can be toggled on/off. Each module has its own set of DLLs, meaning the product can be "shipped" without unnecessary module DLLs. "You need chat functionality? Here's the DLL, drop it in your bin folder, good to go!"
Each DLL is pretty much standalone with no dependency on an other, apart from it's main parent abstraction.
I would like to know, is it possible to create something similar in a React front end? I don't want to have hundreds of react components listed with a bunch of 'if' statements to show/hide them.
I would like each module to be responsible for its own rendering & actions. Adding a brand new feature would be as easy as 'building the extra module' (not updating the 'core' system files to tell it about the extra module).
Gah, I hope that makes sense! Could anyone point me in the right direction? Is this a fools errand? Is it achievable?
Thank you in advance.
This is more question of how to split your frontend code than react specific question. Good news is, it's certainly possible. Take a look at webapack - bundling tool often use with react. I am not sure how exactly modules and DLLs work in C#, but I imagine you have some way how to include different js bundles into them. If so, webpack will help you create these bundles.
I have created an website/application using Angular2. The infrastructure is all set, I have routing completed, sass being processed etc.
I have sections (components) on this website that will display current web standards for our designs (buttons, forms, copy). The purpose of this site is to give our developers a copy/paste solution for markup and sass.
We will most likely create our own css library but they will still need a good visual reference of what each class does and a copy/paste solution.
I know how to develop all the standards, what I don't know how to do is have the DOM display options for the user to copy/paste the code. I could manually enter the code into or tags but this will be hard to maintain and not very clean approach. I'd like to find some solution that will utilize my code and create these tags at run time.
Googling this question leads down the road of using living style guide generators, which i don't want to use... why? I like having the functionality of controlling my own layout and scaling my standards as I see fit with our own technology.
Any ideas?
After exploring this even further I ended circling yet again on documentation tools (KSS) where I would need to rebuild my entire style guide for this functionality using markdown and or JDOCs.
Solution!
Use CodePen, its free to signup however there are some nice to have features for a monthly fee. I easily created my code here using SASS, HTML and CSS libraries. CodePen has a great EMBED feature whereas I could copy/paste html or iframe right to my styleguide.
Problem is now solved, and we have have a dynamic Web & UI Styleguide.
Hope this method helps others in my situation.
I have few queries on selecting Ionic framework for our Hybrid app project. Since I have not used Ionic before, few queries may seem idiotic. But i would request all to share their thoughts.
Q1. How easy it is to customize any ionic components as per project requirement in both JavaScript and CSS level?
Q2. How much overhead ionic components create in terms of DOM, Memory usage?
Q3. In case of collection-repeat, say i want to display 10 items out of 1000 items at a time. So at any point in time only say, will there be only 10 divs and will only new data be injected in the previous created divs?
Q4. Say, I have selected Ionic for our project but don't need all the UI or other components in it. So does Ionic gives the flexibility to exclude those components from the framework itself and use the rest?
Q5. How easy it is to include an external library into Ionic if required?
Q6. How easy to debug and Ionic app and the tools available?
Q1. Since Ionic is based on SCSS, it's really easy to customize the visual aspects. I did a video about working with scss and Ionic. As for the javascript side of things, if you know how to work with directives, you should be good.
Q2. Ionic aims to the keep the DOM nice and lean, and not change the DOM like you would with jQuery. As far as memory usage, that really depends on the code you write. You still need to write good code to make sure there aren't memory leaks any where.
Q3. Collection-Repeat doesn't really work that way. Plus when you start dealing with different screen heights, it's not going to be easy to deal with. The best why that we've come up with to deal with that is to just render how ever many it will take to fill the view.
Q4. At the moment no, if you start a project with the CLI, you get the whole bundle. Down the road we're thinking about breaking things into external components, but it's not set up yet.
Q5. It's Angular, so if you have another angular directive that you want to include, the process is really simple. Just include the script tag and inject the module as a dependency. If it's not an angular module, then it's a bit more work to wrap it in a directive, but there are plenty of tutorials out there to help.
Q6. The best thing to remember is that we're dealing with a webview, so you can do a lot of debugging right from chrome on desktop. If you need more debugging once you're on a device, iOS lets you debug right from safari on desktop, and android 4.4+ let's you debug app on a device with chrome.