Trying to access common Typescript enums from both Client and NodeJS server - enums

I am trying to access enums written in a Typescript file from both the server and the client. The file is called SocketEndpoints.ts and contains enum SocketMessages.
enum SocketMessages{
CONNECTION_SUCCESSFUL
}
I am able call the enum from the client side by using typescript reference tags. However, using the reference tag alone from the server side (and not using any import/require) leads to an error:
message: endPointModule.SocketMessages.CONNECTION_SUCCESSFUL
^
TypeError: Cannot read property 'CONNECTION_SUCCESSFUL' of undefined
As mentioned in one of the answers below, I have to use import/require statement in the server program which runs on NodeJS and "export" the enum. However, using the "export" keyword causes the enum to be inaccessible from the client. Please help me figure out a way to keep this enum commonly accessible from server and client with simplicity. I'd prefer to use only reference tags.
As shown in the answer for this question:
stackoverflow.com/questions/14659996/reference-tag-pollutes-modules-using-typescript
The typescript compiler should traverse all referenced files and include its code in the compiled javascript output. But the javascript output for server side programs don't seem to have that.

You can't mix and match reference tags to implementation files with import directives (think about what's going on in the JavaScript runtime - what is loading that script? Nothing.).
Put export in front of the enums and use import/require to load SocketIoEndpoints.ts.

Related

How to make graphql work on ObservableHQ?

I am using observablehq for playing around with the graphql js library.
However, I fail at importing it and observable complains about this module.
Any hint? Do we need to modify the library to make it observable friendly?
Observable has a Module require debugger for these situations; given a module name, it can often find a way to make it work. E.g., for GraphQL, it suggests using Skypack, which works for me in a notebook:
graphql = import('https://cdn.skypack.dev/graphql#15.4.0')

SwiftAutomation custom record compiler error

I'm using the SwiftAutomation framework to drive a scriptable app that searches for lyrics and returns a AS record. Everything was working correctly, until...
I mapped the AppleScript record to a custom Swift structure according to the SwiftAutomation documentation. The code in the xxxGlue.swift file looks correct, but the compiler complains about SwiftAutomation.SelfUnpacking, with several follow-on errors, when building the MacOSGlues framework.
public struct LFBLyricsInfoRecord: SwiftAutomation.SelfPacking, SwiftAutomation.SelfUnpacking { ... }
--> .../MacOSGlues/LyricsFBAGlue.swift:700:81: No type named 'SelfUnpacking' in module 'SwiftAutomation'
The SelfPacking public protocol is defined in SwiftAutomation, and SelfUnpacking protocol is defined right under it, but without the public keyword. Is that the cause of the compiler error, and if so, how do I fix it?
OK, I finally found a resolution. Seems you have to use different options for the aeglue utility when generating the glue file for the MacOSGlues framework and for the swift file where you actually use your automation, such as in the test project. In my case, where my scriptable app is named LyricsFBA.app, these were:
aeglue -S LyricsFBA.app
for MacOSGlues (generates a LyricsFBAGlue.swift that references SwiftAutomation, but does not include the custom record structure definition), and
aeglue -D -s 'LyricsInfo:lyricsInfo=score:Int+title:String+artist:String+composer:String+link:String+lyrics:String' LyricsFBA.app
for the test program (generatea a LyricsFBAGlue.swift that does not reference SwiftAutomation, but does include the custom record structure definition).

Is there any way to call a library from a client side user interface?

I'm building a user interface in HTML Service for Google Apps Script and I want to be able to call functions from a library that is loaded in the server side .gs file of my script. The client side call to the server side library does not seem to work. Is this possible to do?
I'm pretty new to javascript/apps script so excuse me if I'm mis-stating what's happening here.
UPDATE: Here's the solution I used
On the container bound script:
function libraryHandler(functionName){
return eval("libraryIdentifier." + functionName);
}
In the library:
google.script.run.libraryHandler('myLibraryFunctionName(param1,param2,etc.)')
Make a "dummy" function in the same script where the html is. Make that dummy call your library function.

Output all language strings in Revel?

I'm developing an API Server in Go and the server (at the moment) handles all translations for clients. When an API client fetches particular data it also asks for the translations that are available for the given section.
Ideally I want to have the following folder structure:
/messages
/home.en
/home.fr
/home.sv
/news.en
/news.fr
/news.sv
Where news and home are distinct modules.
Now the question I have for Revel is is it possible to fetch ALL language strings for a given module and given locale? For example pull all home strings for en-US.
EDIT:
I would like the output (something I can return to the client) a key:value string of translations.
Any guidance would be appreciated.
It seems to me that revel uses messaged based translation (just like gettext does), so you need
the original string to get the translation. These strings are stored in Config objects,
which are themselves stored in messages of i18n.go, sorted by language.
As you can see, this mapping is not exported, so you can't access it. The best way
to fix this is to write a function for what you want (getting the config by supplying a language)
or exporting one of the existing functions and create a pull request for revel.
You may workaround this by copying the code of loadMessageFile or by forking your version
of revel and exporting loadMessageFile or parseMessagesFile. This also is a great opportunity
to create a pull request.
Note that the localizations are stored in a INI file format parsed by robfig/config,
so manually parsing is also an option (although not recommended).

Magento API not working with wsdl.exe but works with Soap UI

I'm trying to integrate Magento 1.7 with a C# application.
When I tried to use the "Add Service Reference" function in Visual Studio, it finds the service and all the operations but when I click OK, it doesn't generate anything. i.e. the Reference.cs file is almost empty (only has one line with namespace).
I tried using wsdl.exe to generate the proxy in command prompt and I got the following error:
R2718: A wsdl:binding in a DESCRIPTION MUST have the same set of wsdl:operations as the wsdl:portType to which it refers.
- Operation 'catalogProductAttributeRemove' on portType 'Mage_Api_Model_Server_Wsi_HandlerPortType' from namespace 'urn:Magento' has no matching binding.
For more details on the WS-I Basic Profile v1.1, see the specification
at http://www.ws-i.org/Profiles/BasicProfile-1.1.html.
Error: Unable to import binding 'Mage_Api_Model_Server_Wsi_HandlerBinding' from namespace 'urn:Magento'.
- The operation 'catalogProductAttributeRemove' on portType 'Mage_Api_Model_Server_Wsi_HandlerPortType' from namespace 'urn:Magento' had the following syntax
error: The operation has no matching binding. Check if the operation, input and output names in the Binding section match with the corresponding names in the PortType section.
I then tried using Soap UI to load the same wsdl and it works fine. The proxy was generated and I can make calls without any problems.
The original wsdl file is here: https://gist.github.com/4514723
except I have replaced line 6297 with an example url.
So my questsion is why was Soap UI able to generate the proxies and making calls without any problems but Visual Studio can't? How can I fix it?
See Generate a Web Service Client in WS-I compliance mode .
You will need to modify your Magento code to correct the WS-I compliant WSDL definition in app\code\core\Mage\Catalog\etc\wsi.xml.
The SOAP UI is probably more tolerant of mistakes in WSDLs compared to other .NET/Java tooling.

Resources