As a fairly Microsoft-centric and predominantly back-end programmer, tackling all of these (cool) new technologies all at once has proved pretty daunting. I'm fairly pleased to say that I've got a lot of things wired together and that I feel as if i'm very close to breaking through one last hurdle to a point where i can finally begin to work and produce code efficiently in this brave new world, but there's a major obstacle I'm hung up right now. This is all new to me so i'll try to explain as i can:
I'm using VS 2015 and building up a DNX ASP.NET 4.5 MVC 6 web application. I've used NPM to install react, flux, and all manner of supporting modules. I'm working on my first fully-functional JSX screen which is using the flux pattern to load data and I'm receiving callbacks from my store when the data is loaded from an API service.
I love being able to use the require('xxx') syntax to chain the dependencies together, so I've formed that habit and i'm using browserify & reactify from my gulp task to manage the dependencies, gather all of the input files, and convert my JSX files to JS at, er, gulp-time i guess.
The issue i'm running into now is one that I never expected: when I use require() in a JS file to include a JSX source file that defines one of my react components and then attempt to mount an instance of that component using ReactDOM.render and JSX syntax, i'm receiving the following error:
Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components). Check the render method of xxx.
Up to this point in the other areas of my app I've always included the react components thusly:
ReactDOM.render(<MyComponent />, $("#reactTarget")[0]);
That has always worked. But now that I've bought in to the browserify world to chain these source files together, if i include the line
var MyComponent = require('./MyComponent.jsx');
...and then proceed to try to include an instance of the component with:
ReactDOM.render(<MyComponent />, $("#reactTarget")[0]);
I receive the error above. Now given that all of this is new and somewhat fuzzy to me, i'm not 100% sure that it's the browserify aspect of this which is causing the issue, but it sure feels like it.
I've also tried react.createClass, passing in the 'MyComponent' variable from the requires line, but no joy.
I have this mostly working but of course putting the data on the screen - in this case using react - is the whole point of the thing so, the fact that i now have a functional dispatcher, actions, stores and API calls is exciting but i can no longer simply compose my react components as i used to.
what am i missing here? There must be a way to combine these techniques and technologies but i haven't been able to find an example that equates to this particular combination.
Thanks in advance.
I sometimes wonder what life would be like if I were a smarter animal. I've just spent an entire day - a weekend day, no less, chasing down phantom solutions and alternate configurations until I wanted to cry when in fact my issue was that I'd left off the 's' in module.exports at the end of my component definition. That bloody 's' cost me years of my life, I suspect. That's what I get for not copying/pasting when I'm toying with tings I barely understand. I guess I learned a lot in the process, maybe I'll get those hours back over time.
Thanks to anyone who made an effort here, or even pondered it at all.
Related
at work I'm forced to use flow type, it is however extremely slow, here is a video demonstrating the issue:
https://www.youtube.com/watch?v=hloQX8wG0t0
I already tried several things, such as deleting flow-typed definitions, getting rid of circular dependencies, etc...
At this point I'm out of ideas, I also don't know how to debug the thing, does anyone have an idea how to see the dependency tree that is generated after saving/each keystroke?
Edit 1:
Here is my current .flowconfig:
[ignore]
.*/node_modules/react-native-keyboard-aware-scroll-view/.*
.*/node_modules/react-native-fbsdk/.*
.*/node_modules/#react-native-community/picker.*
.*/node_modules/#react-native-community/slider.*
; remove when flow is updated. Currently leads to "Cannot assign rest to restState because rest [1] is incompatible with State [2]."
.*/node_modules/redux-persist/lib/persistReducer.js.flow
.*/node_modules/recompose/dist/Recompose.cjs.js.flow
; Ignores sub apps
.*/firebase/**
.*/webapp/**
.*/node_modules/react-native-androw/src.*
; Migration to RN 0,64 causes some random errors
.*/node_modules/react-navigation-redux-helpers
.*/node_modules/react-navigation-redux-helpers
.*/node_modules/react-native-calendars
; .*/node_modules/react-native/Libraries/Interaction
; .*/node_modules/react-native/Libraries/Logbox/Data
; We fork some components by platform
.*/*[.]android.js
; Ignore "BUCK" generated dirs
<PROJECT_ROOT>/\.buckd/
; Ignore polyfills
node_modules/react-native/Libraries/polyfills/.*
; Flow doesn't support platforms
.*/Libraries/Utilities/LoadingView.js
[untyped]
.*/node_modules/#react-native-community/cli/.*/.*
.*/node_modules/react-native-confetti-cannon/.*
.*/node_modules/react-native-linear-gradient/.*
[libs]
node_modules/react-native/interface.js
node_modules/react-native/flow/
flow/libs
[options]
emoji=true
server.max_workers=1
sharedmemory.hash_table_pow=22
esproposal.optional_chaining=enable
esproposal.nullish_coalescing=enable
; RN 0.64 turns this on, our codebase explodes
; exact_by_default=true
module.file_ext=.js
module.file_ext=.json
module.file_ext=.ios.js
module.system.node.allow_root_relative=true
munge_underscores=true
module.name_mapper='^react-native/\(.*\)$' -> '<PROJECT_ROOT>/node_modules/react-native/\1'
module.name_mapper='^#?[./a-zA-Z0-9$_-]+\.\(bmp\|gif\|jpg\|jpeg\|png\|psd\|svg\|webp\|m4v\|mov\|mp4\|mpeg\|mpg\|webm\|aac\|aiff\|caf\|m4a\|mp3\|wav\|html\|pdf\)$' -> '<PROJECT_ROOT>/node_modules/react-native/Libraries/Image/RelativeImageStub'
module.name_mapper.extension='svg' -> '<PROJECT_ROOT>/flow/SVGFlowStub.js'
suppress_type=$FlowIssue
suppress_type=$FlowFixMe
suppress_type=$FlowFixMeProps
suppress_type=$FlowFixMeState
; Types first is the architecture that forces very very strict rules (always export typed results)
; In order to increase the performance of flow (it is painfully slow)
; However our codebase is in no way shape or form ready for this (it throws around 567 type errors)
types_first=false
[lints]
sketchy-null-number=warn
sketchy-null-mixed=warn
sketchy-number=warn
untyped-type-import=warn
nonstrict-import=warn
deprecated-type=warn
unsafe-getters-setters=warn
unnecessary-invariant=warn
signature-verification-failure=warn
[strict]
deprecated-type
nonstrict-import
sketchy-null
unclear-type
unsafe-getters-setters
untyped-import
untyped-type-import
[version]
^0.137.0
I also tried a different flow plugin because I thought it could be related to the plugin making too many requests to the flow server, that improves the performance a little bit, but not significantly
Edit 2:
I just tried a bunch of things, namely deleting a bunch of typings that we had for recompose, then also tried extracting a large part of the types to a libDef... still nothing
I really think the problem is our architecture, we basically have declared all of our types in a types/index.js file, every time we want to use them we import them manually e.g. import type { UUID } from 'src/types', and since ALL the types are declared there then the dependency tree is not wrong and it needs to check 400+ files on every change/save
Edit 3
I ended up parsing the entire app's dependency tree to figure out if something was really wrong... came to the conclusion that flow is doing nothing wrong, but our imports are to blame, mostly (I think) due to Redux and Sagas, pulling one import end-ups re-checking the entire app.
You can find my how I figured it out here:
https://ospfranco.com/post/2021/08/25/how-to-visualize-flowtype-dependency-tree/
Many thanks!
I ended up parsing the entire app's dependency tree to figure out if something was really wrong... came to the conclusion that flow is doing nothing wrong, but our imports are to blame, mostly (I think) due to Redux and Sagas, pulling one import end-ups re-checking the entire app.
You can find my how I figured it out here:
https://ospfranco.com/post/2021/08/25/how-to-visualize-flowtype-dependency-tree/
https://www.reddit.com/r/Clojure/comments/4el0xi/how_to_use_an_existing_reactjs_component_with/
There is this existing post about using existing ReactJS components in a CLJS/Reagent project. I'm looking to do the opposite. I have a bunch of CLJS components and would like to compile them into a ui library of some sort so that they can be used by React developers. That is, if I have a button CLJS component, I would like to be able to render that Button using < Button /> or mylib.Button(_) etc.. in a React/js app file.
I have read this - https://shadow-cljs.github.io/docs/UsersGuide.html#target-node-library - extensively but it's not quite working out. I've been using ":target :node-library" and I can get simple functions (that return strings/numbers, for example) to compile and work in my app, etc.. but it doesn't work for entire components. For example, my cljs button component takes in :
defn button [props & children]
but when I try to pass in these parameters (I call {lib.button({}, {})} in my App.js file), I get errors like "No protocol method IMap.-dissoc defined", because I'm trying to pass JS objects into CLJS-only functions, I believe. Not sure how to resolve this..
I can explain more on this if it would help clarify. It would also be super helpful if anyone had a reference demo project or any resources they could link me to.
I only have a few suggestions:
You can try to build a new sample project to consume your library with lein new figwheel myproject and use JavaScript interop to move one step at a time closer to the native JS way of using your library.
You can create an interface namespace that can consume JS objects and wrap these into Clojure data structures to sort out the protocol errors you're seeing, eg. functions that take a props parameter and pass down (js->clj props) to the rest of the code underneath.
For the authoritative source, check the Reagent docs, especially this: http://reagent-project.github.io/docs/master/InteropWithReact.html#creating-react-components-from-reagent-components
I've been looking to develop a method for loading modules and/or components into an AOT-compiled Angular 4 application and been stymied by a variety of solutions that never quite seem to get me where I want to be.
My requirements are as such:
My main application is AOT compiled, and has no knowledge of what it is loading until runtime, so I cannot specifically identify my dynamic module as an entry component at compile time (which is explicitly necessary for the 'dynamic' component loading example presented on Angular.io)
I'd ideally love to be able to pull the code from a back end database via a GET request, but I can survive it simply living in a folder alongside the compiled site.
I'm using Webpack to compile my main application, breaking it into chunks - and so a lot of the SystemJS based solutions seem like dead ends - based on my current research, I could be wrong about this.
I don't need to know or have access to any components of my main application directly - in essence, I'd be loading one angular app into another, with the dynamically loaded module only perhaps having a few tightly controlled explicit interface points with the parent application.
I've explored using tools like SystemJsNgModuleLoader - which seems to require that I have the Angular compiler present, which I'm happy to do if AOT somehow allowed me to include it even if I'm not using it elsewhere. I've also looked into directly compiling my dynamic module using ngc and loading the resulting ngfactory and compiled component/module, but I'm not clear if this is at all possible or if so - what tools Angular makes available to do so. I have also seen references to ANALYZE_FOR_ENTRY_COMPONENTS - but can't clearly dig up what the limitations of this are, as first analysis indicates its not quite what I'm looking for either.
I had assumed I might be able to define a common interface and then simply make a get request to bring my dynamic component into my application - but Angular seems painfully allergic to anything I try to do short of stepping outside of it alltogether and trying to attach non-angular code to the DOM directly.
Is what I'm trying to do even possible? Does Angular 2+ simply despise this kind of on the fly modification of its internal application architecture?
I think I found an article that describes exactly what you are trying to do. In short you need to take over the bootstrap lifecycle.
The magic is in this snippet here.
import {AComponentNgFactory, BComponentNgFactory} from './components.ngfactory.ts';
#NgModule({
imports: [BrowserModule],
declarations: [AComponent, BComponent]
})
export class AppModule {
ngDoBootstrap(app) {
fetch('url/to/fetch/component/name')
.then((name)=>{ this.bootstrapRootComponent(app, name)});
}
bootstrapRootComponent(app, name) {
const options = {
'a-comp': AComponentNgFactory,
'b-comp': BComponentNgFactory
};
https://blog.angularindepth.com/how-to-manually-bootstrap-an-angular-application-9a36ccf86429
recently I started to work on some big project written in php/js.
It is really big and I have constant problem of backtracing what functions are called where.
Is there any tool, that would import all the code files and draw/write connections between classes, objects, functions and such?
Regards
BOUML can create UML diagrams out of your code
http://www.bouml.fr/
old 4.23 version is also free if that is needed
http://download.cnet.com/BOUML/3000-2094_4-10788888.html
I am using Intellij IDEA with the PHP Storm Plugin for my PHP/JS-Projects. There I'm able to right click a function and choose "Find Usage ALT+F7". Now I can see, where this function is getting called.
Intellij IDEA/PHP-Storm is also able to generate UML-Diagrams if needed.
I guess Netbeans, Eclipse+PHP-Plugin do have similar functions [maybe execpt of the uml-generator], if you need an IDE at no costs.
Based on recommendations for the preparation for Ember 2.0...
• In general, replace views + controllers with components
• Only use controllers at the route level...
...we're supposed to eschew Controllers and Views in favor of Components. I haven't been able to figure out and/or understand how to generate Components that aren't direct parents of the components folder, i.e. components/component-name.js.
My current controllers folder looks something like:
/controllers
/account
index.js
edit.js
/business
index.js
Basically, there are sub-folders that group logic based on the sections of the application. How do I accomplish this with just components?
Seeing that components must have a "-" in them, I tried, but get an error...
ember generate component account/index-module.js
You specified "account/index-module.js", but due to a bug in Handlebars (< 2.0) slashes within components/helpers are not allowed.
Do all components have to be like
components
account-index.js
account-new.js
business-index.js
i.e. all in the same folder? This will start to get out of hand with the addition of what I actually consider to be components (things like video-viewer.js, text-editor.js, radio-button.js).
I would really like to have components in sub-folders, but unsure how to do this.
components
/media
/audio
audio-player.js
/video
video-player.js
/text-editing
text-editor.js
editor-toolbar.js
My components folder is already gross and I just got started:
Is it okay to leave the account/business logic in Controllers (seeing that it does say you should only use controllers at the Route level)?
I'm really confused about this "all components, all the time" convention.
Ok, so I had the same problem and as of ember 1.9-beta.3 (that's the version I tested). It is possible to have components nested under resource directories.
That means that you can have a "user" route or resource. And let's say you have a component which you only want to use with the user resource, so you want to put the component under the resource directory.
The way to do it is to put the component under the resource directory app/pods/user/component-name/template.hbs. The important part is to remember that components must have a dash in their name. It can't be just .../user/component it has to be .../user/component-name with a dash. Then you can use the component as {{user/component-name}} in your templates.
Also I think this is only possible when you're using the pod structure.
Ok, I think this question/answer needs a bit of an update for 2019. I have been using Ember for all of about a month, and my components folder has already become a pigpen. And the tutorial and main API docs don't really cover how to organize your components.
So I did a search of course. And the only answers I could find (like this one) are from around 2014-2015, and don't reflect modern Ember. I was about to accept my fate when I found this in the Ember syntax conversion guide.
(Note to the Ember folks: This is an important issue, one that almost every new user will encounter. It should feature a bit more prominently in the documentation. Maybe not the tutorial, but definitely in Components section)
You can in fact generate components under a sub-folder in Ember as such:
$ ember generate component foo/bar-baz
installing component
create app/components/foo/bar-baz.js
create app/templates/components/foo/bar-baz.hbs
installing component-test
create tests/integration/components/foo/bar-baz-test.js
So that's great, the files are created under components/foo and templates/components/foo. And to resolve the name of the component for use in another template, you can use either the old style syntax:
{{foo/bar-baz }}
Or the new style angle bracket syntax:
<Foo::BarBaz />
As the assertion suggests this is due to Handlebars 1.x, and will be available soon.
Ember 1.9 beta builds currently support this, though I'm not positive if ember-cli's resolver would work with it right now. You can read more about Handlebars 2.0 here.
Using a pods structure will also help with organization, and I believe is going to be the recommended strategy going forward.
For now, I'd suggest not to worry about it! Remember the transition plan will be smooth, and as the official releases come out for Ember and Ember CLI, you'll get deprecation warnings.