JavaScript专题之惰性函数

[yangtao2o]

惰性函数

惰性函数就是解决每次都要进行判断的这个问题，解决原理很简单，重写函数。

var foo = function() {
  var t = new Date();
  foo = function() {
    return t;
  };
  return foo();
};

让我们看一下打印结果，是不是如此：

console.log("初始化：", foo);
console.log("调用：", foo());
console.log("之后：", foo);
// 初始化： ƒ () {
//   var t = new Date();
//   foo = function() {
//     return t;
//   };
//   return foo();
// }
// 调用： Sun Apr 05 2020 17:17:41 GMT+0800 (中国标准时间)
// 之后： ƒ () {
//     return t;
//   }

再比如 DOM 事件判断，每次都需要判断：

function addEvent(type, el, fn) {
  if (window.addEventListener) {
    el.addEventListener(type, fn, false);
  } else if (window.attachEvent) {
    el.attachEvent("on" + type, fn);
  }
}

利用惰性函数，我们可以这样做：

function addEvent(type, el, fn) {
  if (window.addEventListener) {
    el.addEventListener(type, fn, false);
    addEvent = function(type, el, fn) {
      el.addEventListener(type, fn, false);
    };
  } else if (window.attachEvent) {
    el.attachEvent("on" + type, fn);
    addEvent = function(type, el, fn) {
      el.attachEvent("on" + type, fn);
    };
  }
}

测试：

var container = document.getElementById("container");

console.log("初始化：", addEvent);

var handle = function() {
  console.log("被触发了");
  console.log("之后：", addEvent);
};

addEvent("click", container, handle);

触发结果：

// 初始化： ƒ addEvent(type, el, fn) {
//   if (window.addEventListener) {
//     el.addEventListener(type, fn, false);
//     addEvent = function(type, el, fn) {
//       el.addEventListener(type, fn, false);
//     }
//   } else …
// 被触发了
// 之后： ƒ (type, el, fn) {
//       el.addEventListener(type, fn, false);
//     }

使用闭包，初始化就完成对应事件：

var addEvent = (function(type, el, fn) {
  if (window.addEventListener) {
    return function(type, el, fn) {
      el.addEventListener(type, fn, false);
    }
  } else if (window.attachEvent) {
    return function(type, el ,fn) {
      el.attachEvent("on" + type, fn);
    }
  }
})();

// 初始化： ƒ (type, el, fn) {
//       el.addEventListener(type, fn, false);
//     }
// 被触发了
// 之后： ƒ (type, el, fn) {
//       el.addEventListener(type, fn, false);
//     }

学习资料：JavaScript专题之惰性函数

[steffenschaefer]

The whole IntelliJ IDEA stuff is very complex compared with what is needed to support Eclipse. I checked the wole thing some months ago. I'll try to write down what I remember about it....

If I create a new GWT project in IntelliJ I get the following things preconfigured:

• A library referencing gwt-user
• Web facet
• GWT facet
  • referencing GWT SDK
  • referencing Web facet
• exploded-war artifact
  • Referencing Web facet, GWT facet output and gwt-servlet.jar
• Module containing the facets and referencing the gwt-user library

The whole stuff is only necessary if you have a fully feature GWT web application. If you simply need the GWT compiler, you will only need a subset (mainly the GWT facet with SDK + gwt-user library).

If using Gradle's "idea" plugin, you won't get anything of the above mentioned. So to really support IntelliJ integration, the gwt-gradle-plugin would have to do everything mentioned above depending on weather you have a web application or not. In my opinion, much of that stuff would better be part of Gradle's "idea" plugin, but I guess this won't happen.

If using IntelliJ's Gradle plugin, IntelliJ will generate the artifact and war facet for you. If the gwt-gradle-plugin would generate the above mentioned things, you will have some duplicates. So in this case, the gwt-gradle-plugin would only have to generate a subset of those things and generate those to work with the ones generated by IntelliJ itself. A problem would be that you would have to manipulate e.g. the artifact generated by IntelliJ to respect the GWT specific stuff (e.g. the GWT compiler output and gwt-servlet).

So this isn't really ideal.

Back to the original question: I don't really see how adding the mentioned configurations to the provided Classpath of the IntelliJ project. As far as I see, this only enables IntelliJ to do a working Java compilation but it doesn't enable IntelliJ to provide real GWT support. I think, the clean way would be to do at least the GWT SDK, GWT facet and gwt-user library stuff to have some usefull support. But this wouldn't solve the whole GWT web application thing.

Sorry if I'm totally wrong about this, but I don't use IntelliJ often. To be hones, I only used it to look what it generates for a GWT project :)

[jnehlmeier]

The Gradle "idea" plugin has become less important as Gradle support in IntelliJ has been greatly improved. IntelliJ uses the Gradle Tooling API to get information about the project and then configures the project accordingly.

I have just created a Gradle project with a GWT module and a web.xml in src/main/webapp/WEB-INF. The gradle build file applies the plugins: idea, java, gwt, war. I have then deleted all IntelliJ project settings and imported the project using IntelliJ's "import Gradle project" feature.

It detects GWT and Web facet (done via file detection of web.xml and the GWT module) and creates four artifacts (a normal one and a draft one both packed and exploded). The only thing it doesn't do is to tell the GWT facet which Web facet to use and it does not add GWT compiler output to the Web facet. Also not adding gwt-servlet.jar to the artifact seems to be an IntelliJ decision as it also doesn't do so automatically if you create a GWT+Web project in IntelliJ. You have to do that manually. So overall the Gradle import is actually not that bad.

I think at the end it would be enough for your plugin to just put GWT SDK on classpath the way I do it in my build files so that Java compilation does not fail and let IntelliJ figure out the rest.

If you want to make it truly portable and fool proof (e.g. configure GWT compiler / DevMode parameters correctly inside the IDE based on Gradle build file, etc.) then you have to write out IDE configuration files anyways and people must use the Gradle "idea" / "eclipse" plugins before importing the project. In that case it is true that you probably have to do a bit more work for IntelliJ.

But for now I would be happy to have gwtSdk and gwt configurations on class path with provided scope out of the box :) And once IntelliJ reuses gwtSdk libraries for the GWT facet the overall experience would just be a lot better.

[steffenschaefer]

It seems that I have to check your approach :) It really doesn't sound so bad.

[strootman]

I followed the suggestions made by @jnehlmeier, and it worked out pretty well for me. I was previously generating the idea modules from gradle directly, then simply opening them in idea. The gradle import is much cleaner, and I'll be using it from now on.

[Turbo87]

I've just seen this issue here for the first time, but independently I've come to the same solution in PR #45. Works pretty well for me and it also works with the IntelliJ Community Editions, which doesn't have real GWT support.

[Turbo87]

@steffenschaefer this has been resolved by 21a3a3b

[vtsaplin]

The idea plugin support was added almost 2 years ago but the related code is not yet released and so not very useful. It would make sense to consider releasing version 0.7 soon or at least to provide available patches in some intermediate version (i.e 6.1)