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
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).
I'm looking for dock layout engine for angularjs written in typescript. I found Dockspawn but it is written in DART and it's not compatible with the rest of my project. Does somebody know any dock layout engine (even paid ones) for angularjs in typescript?
I think your real problem is that dockspawn was abandoned. This is something I built at my company (which, sorry, we don't sell software)and it turns out that Angular is the worst thing you could use to build a layout engine like this.
Managing scope chains among components that are constantly changing positions, opening/closing, resizing, and floating is entirely too complicated for this type of project. You will end up with 15 step bug reports everywhere, and unless you have a perfect algorithm set in place before ever developing anything you will end up spending weeks re-writing code.
Solution (and not the one you want to hear): drop it. Web design is meant for developing pages within the browser, not for developing windows with tabs within your browser window which is full of tabs. The control and flexibility is very nice, but there is always a way to provide the user with just as much control by setting up panels on the page in the positions in which they will be consistently used the most.
Sooner or later someone will develop what you are looking for and release it, but it probably won't be in Angular and it's definitely going to cost money.
You should be able to use Dockspawn because at runtime DART is JavaScript, so as TypeScript. You just need to find a way to make TypeScript aware of Dockspawn and you can do that using a Type definition file.
The types definition file for Dockspawn is available online.
You can install this kind of files using a tool known as tsd. You can find a basic example here.
The owner of the DurandalJS project is now working at Google on AngularJS Next (v2?) in addition to keeping the current version of DurandalJS maintained. The two frameworks are converging.
http://blog.angularjs.org/2014/04/angular-and-durandal-converge.html
For a new mini-SPA project, which framework would be the best choice specifically with regard to the upgrade path?
I note that Rob Eisenberg has listed a number of tips to help existing DurandalJS users get ready for the next version, so it appears there will be an upgrade path available, but I'm wondering if the upgrade from AngularJS to the next generation framework would be simpler.
http://eisenbergeffect.bluespire.com/preparing-for-durandal-nextgen/
To be clear - I'm more concerned in making the right choice for the future (large SPA, split into multiple mini-SPAs) than for my current needs.
I'm not sure which one would be the best choice for now ... actually I'd say none of them is future save enough. Angular 2.0 is going to be definitely different from 1.0 and of course also from Durandal.
Nevertheless the framework itself maybe not that important. I think you should focus on separating code in reusable components. Whether it is a Angular Service/Factory/Provider or a clean Require Module in Durandal it actually doesn't matter. Getting it into the "NEW" Framework should be just a matter of adding the proper wrappers. As for 2-way-binding use the oberserver plugin to maintain clean POJOs.
The most important change from my perspective in NG2 will be the support of Lifecycle events, so even using those in Durandal now will be somehow supported in NG2. As for composition there for sure will be a way to simulate that easily in NG2 as well.
For current work the only two things important for the decision of the currently used Framework in my opinion are the use of RequireJS and Framework simplicity. Sure you can add it to Angular as well, there are several guides on that, but Durandal was built from ground up with RequireJS in mind. Especially in bigger projects this can save you a lot of headache from missing or wrong dependencies. As of the second argument -> porting Durandal to Angular is not that of a big deal because it's written in an easy and understandable way. Vice-versa may be a totally different story. Getting your custom Directives implemented as a combination of templating and ko-bindings can get pretty hard :)
So as a closing statement, if it's going to be a small project, but with the need for continuous support as well as update to NG2 in future, I'd go with Durandal. Besides RequireJS everything is exchangeable and adaptable. In the case of Angular I'm not sure how drastically the new DI system will change the way of development so that would be a show-stopper for me.
Btw. here is the design-document for NG2. So as you see there kinda everything that is important is gonna change:
Router
Persistance
Directives
Modularization (maybe we finally see RequireJS :) )
in qooxdoo desktop you usually have to develop using the SDK and then "build" your app.
Is there a way to generate something like a qooxdoo.js file with the whole library inside so that you can script script it as you like (like jqueryui or dojo)?
Actually it could be nice to have every widget loaded at runtime like dojo's require("dojo.button") but both the approaches would be nice, just avoiding the build phase.
I hope the question is understandable :)
Thank you everybody!
Don't use the output of the build job to run your code as you develop - as among other things - will minify your code and make debugging very difficult.
If you want to code freely without needing to rebuild when you reference new classes then source-all is the build job for you.
In the root directory of your application, type:
python generate.py source-all
If will include the entire framework in the HTML file generated (you'll find it under source/index.html). This would work well if you are composing the UI from scratch and referencing many new qooxdoo widgets with each browser refresh.
If you add a completely new class of your own, you will need to run the source-all job again to include it.
I use the source build job however for a few reasons:
Habit: source-all didn't exist when I started using qooxdoo
Speed: You can notice a bit of lag it when you refresh the browser to view
your app
References: For a mature app, enough of the framework is
included in the application and its rare to add a new reference and
when you do, its probably in a new class of your own which would
require a re-run of the source job anyway.
I suggest you also look at Default Action Jobs as all the possibilities are explained in detail. Hope this helps.
Please check that thread for a detailed answer: http://qooxdoo.678.n2.nabble.com/Using-qooxdoo-desktop-without-having-to-build-it-td7585015.html;cid=1387453759247-228