We have an old legacy MVC app that has a mixture of UI technologies in it, from razor pages, to JQuery to Vue native.
The problem I have is that the new vue components work great in isolation, but we want to instantiate the component and it's properties from an old javascript file.
Can this be done outside of the Vue entry script?
Essentially we have a Js file that loads a customer and at that point we want to bind the vue component with the customer id. I thought we could use the data dictionary to set the data attribute (which I believe vue maps to the prop) but that doesn't seem to work (there is a watch on the property).
The vue component is being used elsewhere, which is why I don't want to change it.
In a pinch, you can access and modify Vue2 internals from external code using the __vue__ property bound to the DOM element Vue was instantiated on.
This is not officially supported, but Vue's creator says "the official devtool relies on it too, so it's unlikely to change or break." https://github.com/vuejs/vue/issues/5621
I'd recommend keeping the amount of manipulation you do this way to a minimum, but reaching in to set a customer ID should be reasonably straightforward.
(In Vue3 this is somewhat more complicated; you need to do the DOM binding yourself from within Vue.)
Related
I have a web component library built using litElement. We are using these components in a React project and are running into an issue using some of the property binding attribute features. React is throwing an error when using the below syntax.
Property binding examples can be seen here using
.attr="" and ?attr=""
https://lit-element.polymer-project.org/guide/templates
Is there a way to use these property bindings inside a React app with a prefixed "." or "?". I am currently aware that we can use JSON.stringify to pass objects as a string to the attribute but would rather pass the objects as a property vs an attribute.
<my-cust-component .model="${this.someObj} ?mybool="false">
Is there a way to use these property bindings inside a React app with a prefixed "." or "?"
Short answer: no.
The first reason is that those syntaxes are lit-specific constructs that you can only use in its rendering context (inside the template of the WebComponent). The other bad news is that React's peculiar view of DOM and rendering make it one of the most WC-incompatible frameworks: you'll have to rely on attributes and refs to communicate with your web components, no property and event binding.
https://custom-elements-everywhere.com/#react
As someone already said you can't use lit-element syntaxes on the react file but you can listen to web components events in react if you use the wc-reactify lib (i'm using it on my project and works just fine), sometimes listening to events dispatched from the web component on your react application can be a solution.
https://lit-element.polymer-project.org/guide/events
https://www.npmjs.com/package/reactify-wc
I'm working on a static site generator where I'd like to be able to support both reactive JavaScript interaction and standard load-a-fresh-page-into-the-browser hyperlinks. It occurred to me that something like Svelte might be a good fit for this; I could use the server-side rendering support to generate HTML for all my pages, and then I could compile and ship JavaScript components with hydratable: true to support the dynamic features.
One issue I thought of with this approach is that most of my project's components will be entirely static content: just HTML and hyperlinks, without any state or event handlers, and I won't change the props except when I generate a new HTML file for a different page. If I naively generate JavaScript to hydrate all those components at page load time, I could end up with a much larger bundle (and more work done at runtime) than I actually need.
Does Svelte offer any way to optimize this situation? Can I somehow check if a component is a pure function of its props so I can avoid hydrating it if I don't need to? Or is the compiler smart enough to do that for me?
This is a good question that we don't currently have a simple answer for.
It is possible to determine whether an individual component has values that can change — svelte.compile(...) returns an object with a vars property, which is an array of all the values inside the component. Inspecting this array will tell you which values are never reassigned to or mutated. (It won't tell you if a component has event handlers that have side-effects but which don't affect state, which would also be necessary to determine whether a component is entirely static. That's information that we could add in a future 3.x release.)
But it's only half the story. Consider a component that declares a name prop...
<script>
export let name;
</script>
<h1>Hello {name}!</h1>
...and which is used in your app like so:
<Greeting name="world"/>
As far as the compiler is concerned when it compiles the <Greeting> component, the name value could change at any moment, so it's unsafe to treat it as entirely static. But if it could understand your app more holistically, it would be able to replace {name} with world, which would have various benefits.
When hydrating, Svelte assumes that there could be a discrepancy between the existing DOM and what's supposed to be there. In many situations it would be safe to assume otherwise, and skip checking subtrees it knew to be static, which would obviate the need to include them in the generated JS.
As a compiler, Svelte is unusually well-positioned to be able to take advantage of these techniques, but it's work that we haven't undertaken yet. Ideally we'll be able to upgrade the compiler in such a way that your apps will get smaller without anything needing to change. If you're keen to start experimenting with what's possible in the meantime, then the vars property returned from svelte.compile(...) (and also the ast property, I suppose) is the place to start.
We're currently working on a new web mapping solution at our company. So far we decided to build the app using React and OpenLayers 4. Since we want to use the Redux pattern for our architecture there will be one redux store holding the application state.
The problem we face with this stack is as follows:
The map is the central element in our application and its instance needs to be passed to a number of different components. As an example, a tool for drawing features on the map needs a reference to the map instance so that it can add itself to it as an interaction tool.
We discussed how to structure our app to integrate OpenLayers with React in the most reliable way and ended up with two different approaches:
The first approach we discussed is holding a reference to the map object in the application-wide redux store so that it simply can get passed down to any component via the #connect annotation function of react-redux.
While this solution provides an easy access to map we were wondering whether this would be a tractable approach since the store should be kept minimal and the map object never changes throughout the lifecycle of the application.
The second approach considers rendering components like the draw interaction mentioned above as child components of the react map component. The map instance could then be passed down to the children of the map component either directly as a prop or by leveraging reacts context object using the Provider pattern.
However, the react documentation explicitly advises against using context, though we found a number of solutions using this pattern (react-geo, react-leaflet) and also popular libraries like react-redux make use of it.
We therefore thought about using React.Children.map() to clone the child components and then adding map to them as a prop.
I hope the problem we are facing got clear enough. We do not know what would be the better way in terms of react best practices.
What architecture would fit better to the "react way" of designing/managing and application and why?
I'm late to the party here, but six months ago I would have recommended using Context API as Redux was using it. As an alternate solution, I would have simply maintained a global object reference on window.app.cache.
Now, the React Context API is the way to go for this. Hope Saga didn't complicate the project!
i have an SPA designed using features (collection of components).. each component exposes bindable properties and some observable properties for inner state management.. the feature at the top level also exposes bindable properties that are used in implementation views to render out specific funcitonalities.. each feature has data dependencies that pull from APIs and some features depend on each other for values that are bound after data loads...
the problem - how do I best handle app initialization when there's changed events firing from observable/bindable properties all through that initial load. my first thought is to find a way to disable all observable in a single place in code that i then turn on once everythign is loaded and ready to start reacting to cascading changes... does that exist in some low-level aurelia API? the only other alternative is to carefully and tediously map out all dependencies and sprinkle "if(!isInitialized) then exit" statements everywhere but that sounds horrible...
That really depends on when you hydrate your components.
The docs here: http://aurelia.io/docs/fundamentals/components#the-component-lifecycle say that if you do something to properties in bind() lifecycle handler - the change handlers would not be called.
I am working on an assignment for a course in "Coding the Humanities" which involves writing a custom web component. This means I am required to use Polymer even though as far as I can see there is absolutely no added value to doing so.
I want to create a literal chat "room" in which users input a character to identify themselves and can walk around the room bumping into one another after the fashion of robotfindskitten.
My idea was to write each character and its position to a Firebase location, updating everyone's positions in real time, so I need the Firebase JS client- using core-ajax for REST requests isn't fast enough.
The GitHub readme for the core-firebase element consists of a link to a less than helpful component page.
Looking at the core-firebase element itself, I don't see anything that corresponds to the 'value' event; locationChanged has a 'child-added' event handler, but that's it.
Am I crazy for thinking the core-firebase element is just very incomplete? Should I try to write my own 'value' handler? If so, do I just add it to the locationChanged property of the object passed to Polymer()? I'm very confused - I know enough JS that what's happening in the core-firebase code is straddling the limits of my comprehension. (Which might have to do with the this keyword, I don't know.) Any input here would be appreciated. (And yes, I've already remarked to the instructor that I could have handled this using plain old jQuery and Firebase if I didn't have to use Polymer. No word as yet on that.)
Looking at the commits for core-firebase it looks like it's had about two days work on it plus some maintenance, so it wouldn't be surprising if there are missing features.
One nice part about Polymer is that it interops very well with other ways of writing apps. It's totally reasonable and supported to use jQuery and Firebase directly to read from firebase and react to changes. You can still make good use of polymer's templating and databinding by doing this within an element of your own and using Polymer's data binding, templating, and plain old DOM events to propagate those changes throughout your app and render them onto the page.